cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Client not decoding soap fault
Date Mon, 16 Apr 2007 19:05:51 GMT

Sortta reminds me a bit of the CORBA SyncScope policy whereby the client
app can control the sync point for oneways, and thus have confidence
that the oneway has been successfully delivered as far as the local
transport, or the server-side runtime, or even all the ways up to the
target (in which case the oneway is effectively treated as a twoway).

Sounds like we use we use an odd amalgam of different sync points,
depending on whether where the fault is thrown and whether addressing is
in use.

Now we could invent a new policy to allow this to be controlled
explicitly, but what's there currently (in the absence of addressing)
doesn't sound like a good candidate for the default behaviour (which I
think should be SYNC_WITH_TARGET, as a CXF client wouldn't necessary
know a priori that the server-side is also CXF and thus supports this
idea of variable sync points). Also it doesn't make a great deal of
sense to return a fault payload on the wire only for this to be ignored
for the client-side runtime ... better IMO to simply to log the issue on
the server-side by default.


> -----Original Message-----
> From: Andrea Smyth [] 
> Sent: 16 April 2007 17:08
> To:
> Subject: Re: Client not decoding soap fault
> 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><soa
> > 
> p:Fault><faultcode>soap:Server</faultcode><faultstring>FaultThrowingIn
> > terceptor
> > 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?
> Andrea.
> >
> > 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