[
https://issues.apache.org/jira/browse/CXF-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
aaron pieper updated CXF-1418:
------------------------------
Description:
AbstractPhaseInterceptor uses its class name as its ID. PhaseInterceptorChain
rejects any PhaseInterceptors with duplicate IDs. The resulting behavior is
that if you have two instances of an interceptor on the same chain, the second
one is discarded. It can be useful to have to instances of the same interceptor
on an interceptor chain, for example, you might have two XSLT interceptors on a
message that needs to undergo two transformations, or two error-catching
interceptors for different kinds of errors.
There are a few ways to work around this problem, which is why I marked this as
minor:
1. Create an additional interceptor class for each XSLT with different names,
"XsltInterceptorKludge2.java" and "XsltInterceptorKludge3.java".
2. Write a subclass of AbstractSoapInterceptor which provides unique IDs via a
counter mechanism (my-id00, my-id01, my-id02...).
There are a number of viable ways to solve the problem for real:
1. A second argument could be added to the constructors for
AbstractSoapInterceptor or AbstractPhaseInterceptor indicating that a unique ID
should be generated.
2. A subclass of AbstractSoapInterceptor could be provided, with code to
generate a unique ID each time.
3. PhaseInterceptorChain could be modified to accept interceptors with
duplicate IDs, and the current interceptors that rely on this logic could
verify that they're not adding duplicate interceptors.
http://www.nabble.com/forum/ViewPost.jtp?post=15300074
was:
AbstractPhaseInterceptor uses its class name as its ID. PhaseInterceptorChain
rejects any PhaseInterceptors with duplicate IDs. The resulting behavior is
that if you have two instances of an interceptor on the same chain, the second
one is discarded. It can be useful to have to instances of the same interceptor
on an interceptor chain, for example, you might have two XSLT interceptors on a
message that needs to undergo two transformations, or two error-catching
interceptors for two different kinds of interceptors.
There are a few ways to work around this problem, which is why I marked this as
minor:
1. Create an additional interceptor class for each XSLT with different names,
"XsltInterceptorKludge2.java" and "XsltInterceptorKludge3.java".
2. Write a subclass of AbstractSoapInterceptor which provides unique IDs via a
counter mechanism (my-id00, my-id01, my-id02...).
There are a number of viable ways to solve the problem for real:
1. A second argument could be added to the constructors for
AbstractSoapInterceptor or AbstractPhaseInterceptor indicating that a unique ID
should be generated.
2. A subclass of AbstractSoapInterceptor could be provided, with code to
generate a unique ID each time.
3. PhaseInterceptorChain could be modified to accept interceptors with
duplicate IDs, and the current interceptors that rely on this logic could
verify that they're not adding duplicate interceptors.
http://www.nabble.com/forum/ViewPost.jtp?post=15300074
> Problem having multiple interceptors of the same type on the interceptor chain
> ------------------------------------------------------------------------------
>
> Key: CXF-1418
> URL: https://issues.apache.org/jira/browse/CXF-1418
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.4
> Reporter: aaron pieper
> Priority: Minor
>
> AbstractPhaseInterceptor uses its class name as its ID. PhaseInterceptorChain
> rejects any PhaseInterceptors with duplicate IDs. The resulting behavior is
> that if you have two instances of an interceptor on the same chain, the
> second one is discarded. It can be useful to have to instances of the same
> interceptor on an interceptor chain, for example, you might have two XSLT
> interceptors on a message that needs to undergo two transformations, or two
> error-catching interceptors for different kinds of errors.
> There are a few ways to work around this problem, which is why I marked this
> as minor:
> 1. Create an additional interceptor class for each XSLT with different names,
> "XsltInterceptorKludge2.java" and "XsltInterceptorKludge3.java".
> 2. Write a subclass of AbstractSoapInterceptor which provides unique IDs via
> a counter mechanism (my-id00, my-id01, my-id02...).
> There are a number of viable ways to solve the problem for real:
> 1. A second argument could be added to the constructors for
> AbstractSoapInterceptor or AbstractPhaseInterceptor indicating that a unique
> ID should be generated.
> 2. A subclass of AbstractSoapInterceptor could be provided, with code to
> generate a unique ID each time.
> 3. PhaseInterceptorChain could be modified to accept interceptors with
> duplicate IDs, and the current interceptors that rely on this logic could
> verify that they're not adding duplicate interceptors.
> http://www.nabble.com/forum/ViewPost.jtp?post=15300074
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
