Re: [wsbpel] Issue - 219 - proposal to vote

[Prasad Yendluri <pyendluri@webmethods.com>]

Alex,

I don't think we should try and add smart semantics to the fundamental 
error condition that caused the fault. The fault could be caused by a 
bug in the language processor that was exposed by a specific (complex :) 
XPath expression that is involved. By requiring an override to throw the 
correlationViolation fault we could be creating a debug nightmare. I 
think we should let the fault that corresponds to the problem 
recognized  be thrown in this case.  I have learnt to put additional 
catch blocks, when I ran into the fault that was not necessarily 
declared. Saving couple of catch blocks is not worth it in this case. 
Perhaps we can add a caution that indicates multiple fault conditions 
are possible rather than convert into a different fault by a ruling in 
the spec.

Regards, Prasad

Alex Yiu wrote:

> Hi,
>
> If we don't use correlationViolation fault here, there will be a 
> number of possible faults thrown - subLanguageExecutionFault, 
> selectionFailure, incompatibleAssign ... One thing I am trying to 
> avoid here is to ask users to catch all these kinds of faults. I can 
> forsee some of not-so-hardworking BPEL programmers will just use a 
> <catchAll> to handle all these faults instead of having just one 
> <catch> on correlationViolation.
>
> And, those XPath used in the propertyAlias are not shown directly in 
> that part of BPEL source code. I am afraid that a relatively naive 
> BPEL developer will forget all these XPath related faults can happen 
> in a <receive> with correlation.
>
> The programmer can still know what real issues are: the 
> correlationViolation fault details should expose the root cause. (e.g. 
> root cause : selectionFailure : the propertyAlias "/some/xpath" 
> defined "/.../../foo.wsdl" points to zero node)
>
> And, I would say having a higher-level fault/exception to hold the 
> details of underlying rootCause is very commonly used design pattern 
> (at least in Java API world).
>
> See:
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Exception.html#Exception(java.lang.Throwable) 
>
>
> I hope that will help explaining my thoughts on this issue.
> Thanks!
>
> Regards,
> Alex Yiu
>
> Yaron Y. Goland wrote:
>
>> I am uncomfortable with the idea of obscuring a language fault with a 
>> correlation violation. The underlying fault is a language fault and 
>> for debugging and other purposes that is the fault that the 
>> programmer needs to address. As such I believe we should stick with a 
>> language fault in the case that a correlation set can't be initiated 
>> due to a language error.
>>
>> In general having a single fault that can cover multiple different 
>> fault conditions isn't a great idea. It significantly reduces the 
>> value of the fault because the programmer can't be sure what the real 
>> issue is.
>>
>>     Yaron
>>
>> Alex Yiu wrote:
>>
>>> -----------------------------------------------------------
>>> In section "10.2 Defining and Using Correlation Sets"
>>>
>>> After the pargraph beginning with "If multiple correlation sets are 
>>> used
>>> in a message activity", add a paragraph:
>>>
>>> "If an error occurs during executing a propertyAlias used by a
>>> correlation set in a message activity, correlationViolation fault MUST
>>> be thrown, instead of underlying query language related fault (e.g.
>>> selectionFailure)."
>>>
>>> Enrich the description of "correlationViolation" fault in Appendix A:
>>>
>>> FROM:
>>> "Thrown when the contents of the messages that are processed in an
>>> invoke, receive, or reply activity do not match specified correlation
>>> information. "
>>>
>>> TO:
>>> "Thrown when the contents of the messages that are processed in an
>>> invoke, receive, or reply activity do not match specified correlation
>>> information OR when the initiate attribute do not match the state of 
>>> the
>>> correlation information OR when a corresponding propertyAlias fails to
>>> execute"
>>>
>>> -----------------------------------------------------------
>>>
>>> Regards,
>>> Alex Yiu
>>