cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: JaxwsInterceptorRemoverInterceptor and RM
Date Tue, 12 Dec 2006 18:04:26 GMT
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: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
>>
>>    
>>


Mime
View raw message