cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: fault handling logic
Date Tue, 14 Nov 2006 07:45:06 GMT
Glynn, Eoghan wrote:

> 
>  
>
>>>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. 
>  
>
Yes, and that is bad as you pointed out earlier.

>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]?
>  
>
I suppose it could be. Not all the code I write is necessarily tied to 
logic... I think we probably need to still set up the outgoing message 
if its an in-out MEP so we have somewhere to start setting up response 
information.

>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. 
>  
>
Ok, I'm happy to change the semantics.

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

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

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

Regards,
- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message