On Thu, Jan 8, 2009 at 1:13 PM, Simon Laws <[email protected]>wrote:
> > > On Thu, Jan 8, 2009 at 11:09 AM, Mike Edwards < > [email protected]> wrote: > >> Folks, >> >> Perhaps there is a need to fix the spec in this regard. Saying nothing >> about exceptions/faults is not good, since the implied looseness means that >> different runtime vendors could choose alternative approaches with nasty >> effects for end user applications. >> >> Any suggestions for what the spec SHOULD say about exception handling for >> the JMS Binding? >> >> Yours, Mike. >> >> >> ant elder wrote: >> >>> But that spec extract says nothing about how to handle exceptions, the >>> key bit being line 227 which explicitly leaves this out, as does the current >>> OASIS versions of the spec. I did ask the spec guys about this once a while >>> back (not on any mailing list so I can't provide a link) the answer was that >>> as JMS doesn't have any standard definition of fault messages so the SCA JMS >>> spec doesn't define anything here either and how to handle this is SCA >>> runtime specific. (as a slight aside, line 227 already makes the JMS spec >>> inconsistent with JAXWS as a return value is unwrapped XML not wrapped, not >>> sure our current wireformat is doing that correctly). I'm missing the reason >>> this could be considered a "backdoor", its not like doing this would open up >>> any vulnerabilities that i can see so a backdoor to where? >>> >>> Anyway, what to do for 1.4? We did support non-JAXWS exceptions in >>> previous releases so wouldn't it be better to continue doing that in 1.x and >>> perhaps if we really do want to change this then to do it only in 2.x? >>> >>> ...ant >>> >>> On Wed, Jan 7, 2009 at 9:14 PM, Raymond Feng <[email protected]<mailto: >>> [email protected]>> wrote: >>> >>> IMO, the wire format controls how business data and/or fault are >>> represented in the JMSMessage. The following is quoted from the OSOA >>> JMS binding spec 1.0: >>> >>> 217 1.5.2 Default Data Binding >>> 218 The default data binding behavior maps between a JMSMessage and >>> the object(s) expected by >>> 219 the component implementation. We encourage component >>> implementers to avoid exposure of >>> 220 JMS APIs to component implementations, however in the case of an >>> existing implementation that >>> 221 expects a JMSMessage, this provides for simple reuse of that as >>> an SCA component. >>> 222 The message body is mapped to the parameters or return value of >>> the target operation as >>> 223 follows: >>> 224 . If there is a single parameter or return value that is a >>> JMSMessage, then the JMSMessage is >>> 225 passed as is. >>> 226 . Otherwise, the JMSMessage must be a JMS text message >>> containing XML. >>> 227 . If there is a single parameter, or for the return value, the >>> JMS text XML payload is the XML >>> 228 serialization of that parameter according to the WSDL schema for >>> the message. >>> 229 . If there are multiple parameters, then they are encoded in XML >>> using the document wrapped >>> 230 style, according to the WSDL schema for the message. >>> >>> And the SCA java spec says: >>> >>> 1715 1.9. WSDL to Java and Java to WSDL >>> 1716 The SCA Client and Implementation Model for Java applies the >>> WSDL to Java and Java to WSDL mapping >>> 1717 rules as defined by the JAX-WS specification [4] for generating >>> remotable Java interfaces from WSDL >>> 1718 portTypes and vice versa. >>> >>> Based on this, my assumption is for text/xml wire format, we follow >>> the Java to WSDL mapping rules defined by JAXWS. It should also >>> apply to fault data. Passing exceptions as Objects in JMSMessage >>> seems to be a backdoor and it is not consistent with the wire >>> format. It requires both client and service side have the same >>> CheckedException class. >>> >>> >>> Thanks, >>> Raymond >>> >>> >> > Hi Mike > > I think ultimately there should be a statement defining the default > behaviour, i.e. something along the same lines of using XML serialization in > accordance with a WSDL interface description of the fault when the default > onMessage(JMSMessage) pattern is not in force. > > However this does raise the interesting question of whether a facility > should be specified in order to provide alternative fault mappings. Give > what's currently on offer I would assume that that is provided by the > wireFormat feature. > > Simon > and along with alternate fault mappings also alternate destinations for faults as most messaging systems have the concept of exception destinations, dead letter queues etc. ...ant
