cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eoghan Glynn" <eogl...@progress.com>
Subject RE: why does the SOAP CheckFaultInterceptor run in the POST_PROTOCOL phase?
Date Fri, 14 Nov 2008 16:39:00 GMT

Thanks for the quick response Dan, some comments inline ...


> > 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.


Sure, but it could do that equally well near the end of PRE_PROTOCOL phase, say if its configured
to run after the MustUnderstandInterceptor.

Come to think of it though, the ReadHeadersInterceptor runs in the READ phase, so we're gauranteed
the headers are out of the way by the time PRE_PROTOCOL kicks in.

Also, at least in the 2.0.6.x version I'm looking at, once the ReadHeaderInterceptors is done,
the <SOAP:Envelope> element has already been stripped off the XMLStreamReader. So the
CheckFaultInterceptor is nicely tee'd up to read off the <Fault> element, whether it
runs in PRE_PROTOCOL or POST_PROTOCOL.

Of course, another option would be to move the JAX-WS handler interceptors to the POST_PROTOCOL
phase.

 
> > 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.


The JAX-WS 2.0/1 specs seems to say little more than:

"9.3.2.2 handleFault
Called for fault message processing ..."

which seems to imply that handleFault should should be called for a fault message on both
the client- & server-sides. 

Currently in CXF, handleFault is called on a server-side handler for an outgoing fault, but
handleMessage is called on a client-side handler for that same message when inbound. Seems
unlikely that this sort of inconsistency would actually be intended by the spec. Though stranger
things have happened, and obviously you were on the spec EG so you'd have deeper knowledge
of the spec meant to say ... :)

 
> > 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.


Yeah, that would work ... but as you point out, the restriction HTTP sortta makes it a non-runner
in the general case.

Cheers,
Eoghan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message