Problem having multiple interceptors of the same type on the interceptor chain?

[Aaron Pieper <pi...@pragmatics.com>]

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.
-- 
View this message in context: http://www.nabble.com/Problem-having-multiple-interceptors-of-the-same-type-on-the-interceptor-chain--tp15300074p15300074.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Problem having multiple interceptors of the same type on the interceptor chain?

[Glen Mazza <gl...@verizon.net>]

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.

Re: Problem having multiple interceptors of the same type on the interceptor chain?

[Aaron Pieper <pi...@pragmatics.com>]

https://issues.apache.org/jira/browse/CXF-1418

Thanks for the insight. As an end-user configuring CXF's behavior through
XML, it's kind of weird to have CXF's behavior not match the XML I'm giving
it, so I don't agree with keeping the current behavior as the default.
However, I understand that it makes things simpler for the built-in
components, so I guess it's a compromise.


dkulp wrote:
> 
> 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 :-)  )
> 
> 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.
> 

-- 
View this message in context: http://www.nabble.com/Problem-having-multiple-interceptors-of-the-same-type-on-the-interceptor-chain--tp15300074p15306508.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Problem having multiple interceptors of the same type on the interceptor chain?

[Daniel Kulp <dk...@apache.org>]

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
dkulp@apache.org
http://www.dankulp.com/blog