Those are good questions. My argument for a new chain in the CreateSequence case would be that if we don't do that, things get very confusing with different frontends. Right now RM needs to be aware of every frontend and its interceptors IIUC.
Re: encryption/decryption - wouldn't those both need to be done before we can read the CreateSequence anyway? Cheers, Dan Another option would be to allow different interceptors to participate On 12/12/06, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi Dan, I can't remember the details that lead me to add the JaswsInterceptorRemover interceptor at the time but in the absence of further investigation I'd say that is a temporary workaround. I need to investigate the exact problems (some of) the JAX-WS interceptors caused and hope these can can fixed by other means than removing the interceptor. In general I do not think that starting a new chain that has only the interceptors RM needs is good - because what should that be? We know we need the soap binding interceptors, and there is the known dependency on the addressing interceptors, but what about other QS interceptors - or interceptors that perform compression or encryption? This was brought up before but we probably need to start thinking about categorizing interceptors in some way (binding only, QS, mandatory, optional etc.). Cheers, Andrea. 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 [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
