This content has been marked as final.
Show 3 replies
-
1. Re: Exception propagation for one way messaqges
adinn Sep 27, 2007 4:00 AM (in response to adinn)By way of comparison I'll add the following:
glassfish swallows any SOAPFaultException thrown by the implementation of an @Oneway method and does not generate a client side exception
CXF notifies the error by returning a 500 code error to the http client. This results in the JaxWS proxy throwing an exception -
2. Re: Exception propagation for one way messaqges
thomas.diesler Oct 2, 2007 4:53 AM (in response to adinn)Jason sais:
>> When I generate the interface and server stub code the corresponding web
>> methods are tagged with an @OneWay annotation. My question regarding the
>> spec is very simple: what is meant to happen if the implementation of
>> such a one way method throws a SoapFaultException, a ProtocolException
>> or some other Exception? Is the JaxWS implementation supposed to throw a
>> corresponding exception in the client context? The sections of the spec
>> I cited in my original post do not make the answer clear.
No, it can not, it violates the WS-I BP 1.0 which JAX-WS conforms to:
http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16651160
"R2714 - For one-way operations, an INSTANCE MUST NOT return a HTTP
response that contains a SOAP envelope. Specifically, the HTTP response
entity-body must be empty."
That said, you can still present a different WSDL to a consumer than the
semantic one in operation. Just removing @OneWay should do the trick If
a XTS endpoint returns SOAP responses, then it really is a two-way endpoint. -
3. Re: Exception propagation for one way messaqges
jason.greene Oct 2, 2007 9:53 AM (in response to adinn)"adinn" wrote:
CXF notifies the error by returning a 500 code error to the http client. This results in the JaxWS proxy throwing an exception
This isn't correct either. A one way message is not guaranteed to be processed when you submit it, so the response just indicates whether or not transmission, not the processing of the message is successful. So it would not be portable to return a 500 as a fault, nor would it be portable to interpret a 500 from a one way service as meaning anything more than a transmission problem.
Relevant sections:
"The HTTP response to a one-way operation indicates the success or failure of the transmission of the message."
"R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it."
-Jason