[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 219 - proposal to vote
Hi Alex, I understood what you are proposing. I am not convinced that this is a good approach here. IMO a simple cautionary note is better solution here than an encapsulation of all possible faults (here) into something different. Regards, Prasad Alex Yiu wrote: > Prasad, > > First of all, I hope most people would recognize that fault/exception > encapsulation is a valid design pattern. > > The question is when to apply this fault encapsulation concept vs when > to keep the original faults. > > In this case, I still tend to think it is beneficial to users to apply > fault encapsulation here, especially in the light of engine-managed > correlation. > > That is, the same kind of correlationViolation fault should be thrown, > regardless whether the engine-managed correlation header is mal-formed > or the xpath in propertyAlias selection points to zero node in message > payload. > > I hope this may convince you better. > Thanks! > > Regards, > Alex Yiu > > Prasad Yendluri wrote: > >> 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 >>>> >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs >> in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]