cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: JaxwsInterceptorRemoverInterceptor and RM
Date Tue, 19 Dec 2006 13:56:38 GMT


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.

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. 

Cheers,
Eoghan


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 16 December 2006 14:27
> To: cxf-dev@incubator.apache.org
> Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
> 
> Hi Eoghan,
> 
> Thanks for the response. The case I was thinking of was the 
> CreateSequence case. In this case RM really acts as a 
> separate service instead of a mediator. So my thought was: 
> why don't we just switch and dispatch it to a different 
> service. For this to work with different frontends we really 
> need to create some new processing chain IMO. This is a 
> common pattern as we have the same problem with things like 
> WS-MX or WS-AT. It seems we should have some way to redirect 
> a message to a different service.
> 
> Another thing we need to keep in mind is that different 
> frontends will be in operation here. So a 
> Jaxwsinterceptoremover can't work as more than a temporary 
> solution to get RM to work with JAX-WS (as andrea noted in 
> her message I believe).
> 
> Regarding fragility, there are a couple issues we need to 
> address beyond just this case (i.e. I've noticed that both 
> myself and Andrea have had issues with flushing and 
> CachedOutputStreams and we have a gazillion pre_logical 
> interceptors which smells funny to me). However, regarding 
> this issue, I don't know that we need to be interceptor 
> aware. We probably just want to start processing at the 
> beginning of some phase for the new service (say pre_logical 
> - which we might want to do with the fault chain as well).
> If our phases are well defined  I don't think there should be 
> issues. So maybe thats a hint to us... I did write up a long 
> email on that at one point but then I accidentally kicked out 
> the battery from my laptop and lost it :-\ Maybe I will try 
> again, write up a proposal and review our code.
> 
> Regards,
> - Dan
> 
> On 12/12/06, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> > Dan,
> >
> > Does the issue arise for:
> >
> > A) (unACKed) messages re-transmitted by RM, or
> > B) out-of-band protocol messages originated from the RM layer, or
> > C) normal messages mediated by the RM interceptor?
> >
> > In general, I think it would be v. fragile for the RM layer 
> to have to 
> > be aware that another interceptor in the chain is 
> problematic in some 
> > cases (A, B and/or C above), and to expect it effectively 
> route around 
> > this interceptor.
> >
> > Wouldn't it be more straight-forward for the HolderOutInterceptor 
> > itself to detect the problematic case and be tolerant of it?
> >
> > For example, suppose the issue only occurs for RM resends (case A 
> > above). The RM interceptor could set a property on the 
> outMessage to 
> > indicate that its being retransmitted, and the HolderOutInterceptor 
> > could check for this and to allow any message without a 
> holder to pass 
> > thru' unmolested in this case.
> >
> > The more jumping around between different interceptor chains in 
> > mid-traversal that we do (a la the client-side 
> fault-handling case), 
> > the more fragile the dispatch path IMO. Conversely the more 
> tolerant 
> > individual interceptors are to unexpected edge cases, the 
> more robust 
> > the dispatch.
> >
> > Cheers,
> > Eoghan
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 11 December 2006 21:34
> > > To: cxf-dev@incubator.apache.org
> > > Subject: JaxwsInterceptorRemoverInterceptor and RM
> > >
> > > I added a HolderOutInterceptor which handles the holder stuff for 
> > > outgoing invocations. But I noticed that this still gets 
> executed in 
> > > RM scenarios, causing issues as what it expects to be 
> there is not 
> > > there.
> > >
> > > Would it help if RM could do something like this: once it 
> realizes 
> > > there is an RM message, stop the current chain and start 
> a new chain 
> > > at a specified phase. The idea here being that the new chain has 
> > > only the interceptors RM needs.  In code form:
> > >
> > > currentChain.stop();
> > > newChain.doIntercept(message, startPhase);
> > >
> > > This scenario would be needed for the SAAJ case too where 
> we have a 
> > > reversed chain, with a pre-made SAAJ response and need to 
> start it 
> > > somewhere after the first phase.
> > >
> > > Cheers,
> > > - Dan
> > >
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message