cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: JaxwsInterceptorRemoverInterceptor and RM
Date Thu, 04 Jan 2007 16:23:31 GMT

> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 23 December 2006 03:00
> To:
> Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
> Hi Eoghan,
> On 12/19/06, Glynn, Eoghan <> 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
> 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.

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.


View raw message