cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: fault handling logic
Date Mon, 13 Nov 2006 04:05:02 GMT
Eoghan Glynn wrote:

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


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

Hehe, but thats half the fun :-)

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

Do you think there is a case where we'll want to access the old out 
message at all if a fault occurs on the outgoing side? That would be my 
one concern, but I don't know how many cases there would be where we 
would need that Also we might want to think about this in conjunction 
with the issue you bring up below.

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

So to be clear, we need a way to distinguish messages and what part of 
the MEP they are? Do we want to extend this to beyond faults so we can 
look and determine if the message is in, out, in-fault or out-fault? I'm 
not sure if isFault() is good enough as WSDL 2.0 has both in and out 
faults (although I still don't really grok in faults).

One idea might be this:

if (exchange.getInFaultMessage().equals(message)) ...

This is nearly what we're doing now, except we distinguish in and out 
faults. We might also want arbitrary labels:

if (exchange.getMessage(PARTIAL_RESPONSE).equals(message)) ...

Does that help meet your use case?

- Dan

Dan Diephouse
(616) 971-2053
Envoi Solutions LLC

View raw message