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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Kulp
Administrator

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
[hidden email]
http://www.dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Glen Mazza-2
In reply to this post by Aaron Pieper
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Aaron Pieper
In reply to this post by Daniel Kulp
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.
Loading...