[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 258 - UninitializedVariable Fault for Missing Message Parts
This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".
The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.
An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault.
As a result, if not all parts are set when using a message type variable in an <invoke> activity, the standard bpel:uninitializedVariable fault is thrown.
Section 10.3 explains the <toPart> element:
The <toPart> elements, as a group, act as a single virtual <assign>, with each <toPart> acting as a <copy>. The destination of all the <copy>'s is an anonymous temporary WSDL variable, of the type specified by the relevant WSDL operation's input message. (...) Parts not explicitly represented by <toPart> elements result in empty parts in the target anonymous WSDL variable used by the <invoke> activity. (...)
The use of <toPart> instead of inputVariable is a syntax alternative and does not introduce different behavior. Therefore, this is not a place where "empty parts" become acceptable.
In either case, it must be made clear that an <invoke> or <reply> activity IS **USING** ALL PARTS of an (input) message. If a part is not set then the standard bpel:uninitializedVariable fault is thrown.
Submitter's proposal: Add a clarification to the end of the paragraph in section 8.1 which explains the standard fault bpel:uninitializedVariable: An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the invoke and reply activity, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable.
Change the text in section 10.3 from:
Parts not explicitly represented by <toPart> elements result in empty parts in the target anonymous WSDL variable used by the <invoke> activity.to:
Parts not explicitly represented by <toPart> elements result in uninitialized parts in the target anonymous WSDL variable used by the <invoke> activity, which causes the standard fault bpel:uninitializedVariable to be thrown.
To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 258 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 258 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]