[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 182 - Proposal For Vote
Hi all, I have merged most of changes suggested by Yaron as friendly amendment. And, I made a few minor other changes as well. And, I have shown text Yaron (on computer screen during F2F) and he feels comfortable with those text also. Hence, this is updated version of the proposal to vote (attached). Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > The following is a friendly amendment to Alex's proposal but my guess > is that Alex and I will need to discuss it. > Yaron > > Alex Yiu wrote: > >> Hi all, >> >> Yaron and I have been working together to come up the wordings for >> the proposal to tackle Issue 180, 182, and 185 in a consistent manner >> (since all these 3 issues are highly inter-related.) >> >> Please take a look into the proposal attached. I guess we shall try >> to discuss it in F2F, if time allows. >> >> (Note: >> >> * Parts of this proposal draft comes from Yaron. I just finished >> the draft >> of combining pieces right before the long weekend. Hence Yaron >> has NOT got >> a chance to review this version of text yet. (But I personally >> would not >> expect Yaron would have any major disagreement with that.) >> * I still decide to send it off to the TC list, since I want to >> give enough >> time for people to read on this proposal before the F2F >> * This proposal draft has been shared in a smaller group. >> Particularly >> factoring in some of the Satish's friendly amendments. >> >> ) >> >> >> Thanks! >> >> >> Regards, >> Alex Yiu >>Title: Proposal for Issue 180, 182, 185
Proposal for Issue 180, 182, 185
In the case of faults thrown with associated data the fault will be caught as follows: · If there is a catch activity with a matching faultName value that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified catch activity. · Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity with a matching faultName value that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element. · Otherwise if there is a catch activity without a faultName attribute that has a faultVariable whose type matches the type of the fault data then the fault is passed to the identified catch activity. · Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity without a faultName attribute that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element. · Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler. · Otherwise the fault is thrown to the immediately enclosing scope. =================================== 1. If there is a catch activity with a matching faultName value that has a faultVariable or faultMessageType whose type matches the type of the fault data then the fault is passed to the identified catch activity. 2. Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity with a matching faultName value that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element. 3.If there is a catch activity with a matching faultName value that does not specify a faultVariable or faultMessageType value then the fault is passed to the identified catch activity. Note that in this case the fault value will not be available from within the fault handler but will be available to the <rethrow> activity. 4.Otherwise if there is a catch activity without a faultName attribute that has a faultVariable or faultMessageType whose type matches the type of the fault data then the fault is passed to the identified catch activity.5.Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a catch activity without a faultName attribute that has a faultVariable whose type matches the type of the element used to define the part then the fault is passed to the identified catch activity with the faultVariable initialized to the value in the single part’s element. 6. Otherwise if there is a catchAll handler then the fault is passed to the catchAll handler. 7. Otherwise, the fault will be handled by the default fault handler. =================================== · Some suggests to move item (3) down the list of preference of matching to right before item (6). Changes NOT related to this issue: · Fixing some mistakes in Issue 12.1 in item (1) and (4) by adding “faultMessageType”. · Add clarification of default fault handler.
Add after the sentence that ends "...will indicate a variable of the message type for the corresponding fault." If the reply activity is to transmit a fault then the specified fault MUST be defined on the WSDL portType/operation or the reply activity MUST fail with a "bpws:faultNotDefinedinWSDL" fault.
Appendix A:
faultNotDefinedinWSDL
- A fault was submitted to a reply that was not defined on the portType/operation. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]