Can anyone clarify the intention of the WS 2.0 specification regarding the propagation of exceptions from server to client for messages whicih are tagged @OneWay. It is not clear to me whether an exeception generated by the web method implementation is supposed to be caught and handled by generating a corresponding exception for the client call. The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single message and no or messages and is bound ot a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases. I have tested the case mentioned above on JBossWS 2.0.1GA (with AS5.0.0.Beta3), generating either a SOAPFaultException or a WebServiceException. The test invokes the one way method via a client proxy obtained from the generated soap service class. In both cases a client exception was not thrown. However, I'll note that neither is this definitive of what the spec intends nor does it necessarily indicate that this is the behaviour desired by the implementation. The latter point is explained below. An HTTP error was returned to the invoking client and a SOAP fault containing the generated exception details was serialised into the response stream and dispatched back to the client. Affter I patched a bug in the remoting code the soap envelope was read from the http connection response stream as a String. This format was employed because the unmarshaller installed on the connection before invocation was an HTTP unmarshaller, not a SOAP unmarshaller. This appears to explain why the fault was not thrown in the client context. Given all the work involved in returning the SOAP fault I wonder if this was really what was meant to happen? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087841#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...