Glynn, Eoghan wrote:
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: 23 December 2006 03:00
To: [email protected]
Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
Hi Eoghan,
On 12/19/06, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
OK, conceptually I agree with your picture of the RM out-of-band
protocol messages (such as the CreateSequence) being akin to
invocations on a separate service.
However, in practice I'm not sure as to what exactly we'd gain over
the current implementation (where the RM interceptor effectively
services these invocations directly itself).
By not jumping between chains to dispatch the RM out-of-band
invocation,
we avoid having to make the error-prone decision as to exactly what
interceptors this special chain should include. This
question is not
straight-forward, as the request will already have been partially
dispatched on the normal chain, so the special RM chain
would have to
take cognizance of this.
In fact by the time the request has reached the RM
interceptor, i.e.
the point at which we recognize it as an RM out-of-band protocol
message as opposed to an application-level request, most of
the work
has already being done ... so there wouldn't be many (if any)
interceptors that it would make sense to include in a
special chain to
handle the out-of-band messages.
I see your point. The flip side of this though is that there
aren't many frontend specific interceptors in the beginning
of the chain though. The holder/wrapper/logicla interceptors
are at the end at least.
(On a separate note - should the SOAPHandlers even be invoked on an RM
createsequence??)
Hmmm ... that's arguable.
It was certainly needed in Celtix, as the RM layer was partially
implemented as a JAX-WS SoapHandler, as was the WS-A layer. So these
handlers definitely needed to partipate in the dispatch of out-of-band
RM messages like CreateSequence.
On the other, a developer might be surprised to see their
application-level JAX-WS Handlers traversed for what they'd consider
"under the hood" messages (like the RM CreateSequence, or say some
WS-AtomicTransactions out-of-band interaction with a txn coordinator).
But such a surprise could only be educational for them :)
As things stand however, the JAX-WS handler interceptors do not sit well
with RM, or at least with the logging interceptors used by the RM system
test. Hence they're stripped from the chain by the
JaxWSInterceptorRemover.
We could drop all interceptors belong to the "user" phases USER_LOGICAL
(e.g. LogicalHandlerInterceptor), USER_PROTOCOL (that is the phase to
which the SOAPHandlerInterceptor SHOULD belong, it is currently however
in phase PRE_PROTOCOL, don't know why, IMO that's wrong).
Doing so does not depend on the frontend, and therefore would not
pollute dependencies.
We could even make this dropping of user phase interceptors for RM
protocol messages optional. It would happen at the earliest point
possible, which is in the RMSoapInterceptor, in which by looking at the
now decoded WS-A action header the message can be identified as an RM
protocol message. As the RMSoapInterceptor belongs to phase
PRE_PROTOCOL, which (inbound) comes before USER_PROTOCOL, and USER_LOGICAL.
It's not possible however to remove the USER_STREAM interceptors, as
they are one of the first in the inbound chain and are traversed before
we can actually detect that the message is an RM protocol message.
However, I'd agree that the current practice in the RM
implementation of
scanning the remainder of the chain to remove problematic
interceptors
is bad, not least as its dependent on the implementation
details of a
specific (JAX-WS) frontend. So we have to come up with a
better way of
doing this, and if possible I'd prefer to leave these
interceptors in
place in the normal chain, but make them more robust in the
sense of
being tolerant to unexpected message content.
So your proposal is to make the current interceptors more
tolerant of
messages not bound to them? So if I was a
WrapperClassInInterceptor I would check to make sure the
service being invoked was actually a JAX-WS service?
Can you elaborate on how exactly you see this thing working?
Well I was thinking of something even more simple ... the interceptors
should be coded defensively to "expect the unexpected" and simply step
out of the way when that occurs ... e.g. instead of the
HolderOutInterceptor just doing a straight cast of the message parts to
Holder and barfing with ClassCastException on any other type, it would
first check with instanceof to ensure the cast succeeds and otherwise
bail out from handleMessage() immediately.
I'd be very much in favour of this - hence my question: Is it OK to make
the HolderInInterceptor robust by performing a type check before casting
to Holder? Or is there a more efficient way, e.g. check the parameter
type for INOUT first, and only then attempt the cast?
Andrea.
Note that these issues don't just arise in the RM use-case. AFAIK the
Yoko folks ran into similar problems with the JAX-WS interceptors when
mediating a CORBA dispatch.
/Eoghan
