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
