cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: fault handling logic
Date Mon, 13 Nov 2006 10:12:34 GMT

[RESEND - for some reason this mail sent yesterday didn't reach the list, yet Dan's reply
did, very odd ...] 
 
> >2. On the client-side dispatch of an incoming fault, in 
> order to jump to the in-fault-chain, 
> ReadHeaderInterceptor.handleMessage() attempts to retrieve 
> the Endpoint from the exchange *before* correlation occurs, 
> i.e. when the real Exchange for the message is *unknown*. As 
> a result the attempt to abort the current interceptor chain 
> traversal and jump over to the in-fault-chain fails (as 
> getInFaultObserver() can't be called on a non-existent 
> Endpoint). So the SoapxxFaultInInterceptor is never reached 
> and the message.setContent(Exception.class, ...) call never 
> occurs. Hence the message is incorrectly categorized as a 
> partial response by the ClientImpl.
> >
> >Proposal: if the Endpoint is unavailable in 
> ReadHeaderInterceptor, have the ReadHeaderInterceptor mark 
> the message with a "deferred.fault.observer.notification" 
> property and delay and the jump to the in-fault-chain until 
> after the correlation occurs (in the WS-A layer).  
> >
> >  
> >
> Do we want to always defer this and build in correlation into 
> CXF more? 
> i.e. we could have some default correlation mechanism and a 
> CorrelatorInterceptor. It would check to see if the message 
> is a fault and kick it off there instead of kicking off the 
> fault chain in ReadHeadersInterceptor.

Well as long as its *not* done in ReadHeadersInterceptor as is currently
the case, as that can't possibly work when the response is decoupled.
The jump to the fault chain needs to  occur in the WS-A layer at the
earliest, or in a subsequent interceptor as you suggest, so the
Exchange is definitively known.
 
> >4. The semantics of Interceptor.handleFault() are 
> gratuitously different from those of JAX-WS 
> Handler.handleFault(). As far as I can tell, no existing 
> interceptor does anything useful in handleFault(), whereas 
> the WS-A and WS-RM layers both incorrectly expect the 
> handleFault() semantics to be consistent with the JAX-WS 
> case. Also I don't think the JAX-WS wrapper interceptors 
> actually call Handler.handleFault() appropriately (i.e. 
> Handler.handleMessage() is called instead).
> >
> >Proposal: when a fault occurs on the in-chain, we currently 
> unwind the current chain by calling handleFault() on each 
> previously traversed interceptor and then jump to the 
> out-fault-chain, calling handleMessage() on each interceptor 
> with the fault message. I'd propose changing this to drop the 
> unwind, instead call faultMessage() on each interceptor in 
> the out-fault-chain. As a result, it would be clear to the 
> interceptor that:
> >a) a fault has occurred
> >b) the direction of traversal (ì.e. inbound or bound)
> >
> >  
> >
> Yes, the semantics are very different, however if you don't 
> think about the JAX-WS stuff it makes sense. handleFault gets 
> called only if somewhere down the chain a fault occurred. 
> This allows the interceptor to clean up any resources if it 
> needs to. For instance, a database transaction might be 
> rolled back. While this could happen in the fault chain, what 
> happens if there is an error sending the fault message and 
> the necessary interceptor isn't reached? This provides a full 
> proof way to make sure something is cleaned up.

Sure, the current semantics are (belatedly) clear to me, but my
argument is that these semantics cater for a theoretical scenario that
doesn't yet occur in practice, whereas IMO the priority should skewed
towards our current set of specific requirements (in particular the
needs of WS-A, WS-RM and the JAX-WS Handler wrappers).

However, rather than getting side-tracked into an extended discussion
on the merits of the current semantics, lets get to a quick conclusion
on what needs to be done in the short term to get fault handling
working in the decoupled case.

The least WS-A & WS-RM need to know is the direction of traversal and
whether its a fault or a normal message. In order to make the
inbound/outbound direction clear, I proposed dropping the fault
message field on Exchange and consolidating on single in and out
message fields. However the distinction between a normal and fault
message is then lost.

So if we stick with the current handleMessage/handleFault semantics,
then we'd  need something like a new Exchange.isFault() field (so that
in the handleMessage() call on each interceptor in the fault chain,
its clear that message being handled is a fault - note the fact that
the interceptor is part of the fault chain isn't sufficient in itself,
as the same interceptor instance could be used in multiple chains).
Maybe just checking whether message.getContent(Exception.class) is
non-null would be sufficient, but I'm not 100% sure this is always &
only set when fault chains are being traversed.

Cheers,
Eoghan

Mime
View raw message