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
