cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: Client not decoding soap fault
Date Mon, 16 Apr 2007 16:08:19 GMT
Andrea Smyth wrote:

> If a server-side in-interceptor throws a Fault when processing the 
> inbound (soap) message for a oneway request, I can,  using the 
> LoggingOutInterceptor,  see that a soap fault is sent back to the client:
> INFO: Outbound message: <soap:Envelope 
> xmlns:soap=""><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>FaultThrowingInterceptor

> interceptor failed to handle 
> message.</faultstring></soap:Fault></soap:Body></soap:Envelope>
> But the client does not decode the fault and simply throws a Fault (as 
> opposed to a SoapFault) with code: "COULD_NOT_SEND", and message: 
> "Could not send Message. (and a wrapped IOException: Server returned 
> HTTP response code: 500 for URL: ...).

If addressing is used, and the fault throwing interceptor executes after 
the logical addressing interceptor, the client does not receive a Fault 
at all. The reason is that the partial response has already been sent 
(from within the logical addressing interceptor), so all faults 
occurring after that are practically ignored and the client has no idea 
that the actual invocation on the server never occurred.
I don't believe this is correct either. At the very least it is not 
consistent with the non-addressing case where the client can surround 
the oneway invocation with a catch(Fault ...) clause.
BTW an example of such an interceptor would be the logical RM 
interceptor, which executes after the logical addressing interceptor.
Also, I am not quite sure how to interpret the following extract from 
the addressing spec:

 >>In a one-way interaction pattern a source sends a message to a 
destination without any further definition of the interaction. 
"Request-response" is a common interaction pattern that consists of an 
initial message sent by a source endpoint (the request) and a subsequent 
message sent from the destination of the request back to the source (the 
response). A response in this case can be either an application message, 
a fault, or any other message. Note, however, that reply messages may be 
sent as part of other message exchanges as well, and are not restricted 
to the usual single Request, single Response pattern, or to a particular 
WSDL transmission primitive or MEP. The contract between the interacting 
parties may specify that multiple or even a variable number of replies 
be delivered.<<

I would tend to read it as: even if the operation is oneway, the 
contract between the interacting parties may mandate the use of RM, and 
as such require that e.g. non-existent sequence ids result in SoapFaults 
with prescribed fault code. The question is: does this go as far as 
mandating the sending of that fault back to the client, or is it 
sufficient to log such an error on the server side?


> If the message is twoway, the client receives a SoapFault, with 
> faultCode: {}Server and the 
> expected reason.
> Is this intended behaviour? IMO it is not correct, considering that in 
> the first case the correct fault code and faultstring is available it 
> should as well be decoded so the client gets a idea of what went wrong 
> on the server side. In particular, I think the soap fault should be 
> decoded to correctly implement fault handling in addressing and rm, 
> where server side interceptors may fail because of duplicate message 
> ids, duplicate sequence ids, etc. which can occur in the context if 
> both oneway and twoway requests.
> Andrea.

View raw message