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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: 11 December 2006 21:34 > To: [email protected] > 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
