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:59:03 GMT
 
> > 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

I can't think of such a case.

Note that the current fault-handling code goes further than keeping the
old message around in the Exchange, it also copies the entire content
into the new fault message. 

Also on a related point, I don't understand why the current server-side
logic always sets up *both* a normal out-message and a fault message,
when its unclear which of these messages will actually be needed. See
for example OutgoingChainSetupInterceptor.handleMessage()[1]. Surely the
fault message can just be created when and if we're sure we need it,
i.e. in AbstractFaultChainIntiatorObserver.onMessage()[2]?

Why is the above eager setting of the Exchange fault message a bad idea?
Well, its natural for other code to use Exchange.getFaultMessage()!=null
as part of a conditional to determine whether a fault is being processed
(for example the RM interceptor does this). But of course
Exchange.getFaultMessage() will be non-null for any interceptor called
subsequent to the OutgoingChainSetupInterceptor, even if no fault has
occurred ... confusing, fragile, etc. 

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

I'd need to check everywhere Exchange.{get|set}FaultMessage() is
currently called, to ensure that the direction is clear from the context
(... so that it would be a trivial substitution with
{get|set}{In|Out}FaultMessage()).
 
> 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)) ...

I don't think this is needed, as we can recognize partial responses when
we need to by just checking that the message content of type List and
Exception are both null.

Cheers,
Eoghan

[1]
http://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/jav
a/org/apache/cxf/interceptor/OutgoingChainSetupInterceptor.java
[2]
http://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/core/src/main/jav
a/org/apache/cxf/interceptor/AbstractFaultChainIntiatorObserver.java

Mime
View raw message