PhaseInterceptorChain[1] has "add" methods (lines 155 and 169) with a "force" parameter, that, if true, will apparently force the interceptor to be added to the chain (lines 475-496), even if there is another interceptor with the same name.
I guess if you subclass PIC and just override the add() methods at line 151 and 165 to set a force value of "true" instead of "false", that would work. However, this force method is apparently highly infrequently used so I don't know how well tested out it is. Another issue is how to get CXF to use this subclass of PhaseInterceptorChain instead of PIC itself. Anyone know this? Unless I'm missing something, it really looks like this needs to be made more user-friendly. Regards, Glen [1] http://tinyurl.com/ytxfzk Am Dienstag, den 05.02.2008, 15:25 -0800 schrieb Aaron Pieper: > We have a homebrew CXF interceptor which extends AbstractSoapInterceptor. > It's a generic XSLT interceptor which runs the input through a specified > XSLT. We use two of them in our interceptor chain, configuring them with > different XSLTs. However, CXF ignores the second interceptor. It seems like > since AbstractPhaseInterceptor uses the class name for its ID, the second > interceptor is assumed to be a duplicate of the first. > > The simplest workaround is to create an additional interceptor class for > each XSLT with different names, "XsltInterceptorKludge2.java" and > "XsltInterceptorKludge3.java". > > A more complex workaround is to have our interceptor class have a static > counter which increments with each created instance. > > Is this intended behavior of AbstractPhaseInterceptor? It seems unusual to > assume that implementors will only want to have one instance of a given > interceptor in the interceptor chain.
