This is actually as designed as a bunch of the interceptors will behave strangely if put twice in the same chain.
As an example, lets say you have the logging feature configured on the bus, but also have it configured for the endpoint and also a @Feature thing on the code itself. The logging interceptors would then be added three times which would cause some very strange behavior as well as some HUGE performance problems. Another example would be the WS-Addressing interceptors as they each would be processing the addressing headers and sending back partial responses and stuff. If that was configured in multiple places, all kinds of issues would pop up. What might be a workable solution would be to add a method like: boolean allowDuplicates(); to PhaseInterceptor (default it to false in AbstractPhaseInterceptor for compatibility) where an interceptor could say "I'm allowed to be in here more than once". Feel free to log a JIRA for this. (and attach a patch :-) ) BTW: if you can send in a unique ID into the contructor, you can be OK now. AbstractPhaseInterceptor has a constructor where the ID can be passed in. Dan On Tuesday 05 February 2008, Aaron Pieper wrote: > 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. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
