cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL phase?
Date Fri, 14 Nov 2008 15:44:12 GMT

Actually, thinking about it some more....

Another fix MAY be to just update the JAXWSHandlerInvoker to look at the 
SOAPMessage (since it had to part the thing into the SAAJ model anyway) and 
have it call handleFault instead of handleMessage if the body contains a 


On Friday 14 November 2008 10:39:50 am Daniel Kulp wrote:
> On Friday 14 November 2008 10:27:55 am Eoghan Glynn wrote:
> > Folks,
> >
> > Is there any reason why the SOAP CheckFaultInterceptor runs in the
> > POST_PROTOCOL phase, as opposed to PRE_PROTOCOL?
> Well, the basic reason is that to check for a fault, it needs to look at
> the first element in the body.  The headers and envelop and such are
> handled in the PROTOCOL phase, thus, it needs to be checked afterword.
> > The net result is handleFault() is never called for a client-side JAX-WS
> > SOAPHandler, as the CheckFaultInterceptor (which is responbile for
> > determining if a fault is present in the incoming message) is assigned to
> > a phase that runs *after* the PRE_PROTOCOL phase in which the JAX-WS
> > handler chain is traversed. So Handler.handleFault() can never be called,
> > as it isn't yet known that the message actually contains a fault.
> Which MAY be correct.   I'd need to double check the spec and TCK and such.
> (before committing any change in this area, let me know and I'll run the
> tck on it).   The handleFault may be for handling faults that are generated
> as part of processing the normal message.     I'd need to double check on
> that.
> > So before I go fixing this I wanted to check if this apparent
> > mis-ordering was just an oversight, or whether there's method to the
> > madness :)
> That all said, I've THOUGHT about adding a HttpErrorCodeInterceptor or
> something that goes very early in the chain to flip it over to the
> faultInChain if the response code is 500.  That could be done LONG before
> any processing of anything else is done.   Obviously only useful for HTTP
> transport though.     The current implementation means that any stream
> related things only on the faultInChain wouldn't ever get called.  
> Flipping over based on response code would fix that.

Daniel Kulp

View raw message