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
