cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: JaxwsInterceptorRemoverInterceptor and RM
Date Sat, 16 Dec 2006 14:27:18 GMT
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.

- Dan

On 12/12/06, Glynn, Eoghan <> 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 []
> > Sent: 11 December 2006 21:34
> > To:
> > 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
> > |
> >

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message