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.
Agreed.
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
http://netzooid.com
