[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 190 - Adding a switch
Hallo Yaron, I agree, and want to add, that not only in short lived processes ony might want to do such a clean up handling. We for example use a catch all handler to generate an Alert List Task Item and post it to a Portal. This item contains info for restarting the process and for detals. Therefore we like to have a catchAll (on proces scope) which can A) catch system faults (especially from transports) B) catch BPEL faults C) retrieve detailed info (location, fault typ, fault details) Also we like to have a assign.copy whith an xpath expression which might not find any matching element (because the falt type does not support it) for exmple to look for "/mycomany/traceInfo" -----Original Message----- From: Yaron Y. Goland [mailto:firstname.lastname@example.org] Sent: Monday, February 14, 2005 11:19 PM To: wsbpeltc Subject: [wsbpel] Issue 190 - Adding a switch In many processes, especially shorter lived ones, users don't want to require administrative intervention if a process runs into a system fault. They would much rather just put in a fault handler that can detect that a system fault has occurred, clean up any resources the process is using and shut the instance down. 190, as I understand it, would make the previous impossible in a portable way. If we pass 190 then as soon as a system fault occurs the process must terminate. At that point no further standard behavior is possible. At a minimum we should keep the current portable behavior for the many scenarios where it is useful. Potentially we could introduce a switch which could specify that if a system fault is thrown then the process should be terminated. The purpose of the switch is to let the programmer know that they don't ever need to worry about handling system faults in their code because their code will never see the system fault. But I must admit that the utility of the switch is suspect as it depends for its utility on exactly what the admin will do after termination, something that is completely undefined in BPEL. But in any case, we shouldn't remove the current portable behavior. Yaron To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr oup.php.