Re: [wsbpel] Issue 182 - revising its wordings

["Yaron Y. Goland" <ygoland@bea.com>]

Please note that this issue is very much related to but not necessarily 
redundant with issue 141.

	Yaron

Alex Yiu wrote:
> Hi, all,
> 
> Regarding to issue 182:
> The issue description was formulated before the F2F discussion in NY.
> After the discussion, I feel I should generalize the description to accomodate a 
> wider range of proposed solutions.
> 
> ==========================================
> *Issue Subject*: How to add bodies later to BPEL faults without breaking BPEL 
> code written assuming there is no fault body?
> 
> *Description:*
> According to our current fault matching rules IF a fault has a body THEN it can 
> only be three ways - by a catch that specifies the name and body, by a catch 
> that just specifies the body or by catch all. But notice what can't catch it, a 
> catch that just catches on the name.
> 
> That means, if someone needs to add a data body to the fault later (to add 
> optional interesting data) then all existing catches will be broken.
> 
> How do we make it possible for people to later add bodies to BPEL faults without 
> breaking BPEL code written assuming there is no fault body?
> 
> Please note that this problem already affect us on BPEL standard faults. We 
> define BPEL standard faults with their name but without their bodies. If an 
> implementation decides to introduce extra fault information in the body later, 
> all existing fault handlers for that fault will not work. We need to ask users 
> to change their fault handlers or add new fault handlers.
> 
> *Proposed Solution:*
> 
> (A) allow <catch faultName="qname"> to catch with fault data body as well ?
> (B) introduce a standard fault body that is thrown with all BPEL standard 
> faults. And, the fault body will contain an xsd:any ?
> (C) add new version of <catch> fault handler that specifies both a name and a 
> body and can catch either just on name or on both name and body ?
> (D) Other ideas .... ?
> 
> ==========================================
> 
> 
> Thanks!
> 
> *** Peter, sorry for the inconvenience caused.
> 
> 
> Regards,
> Alex Yiu
> 
>