You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "aaron pieper (JIRA)" <ji...@apache.org> on 2008/02/06 13:01:40 UTC

[jira] Created: (CXF-1418) Problem having multiple interceptors of the same type on the interceptor chain

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 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (CXF-1418) Problem having multiple interceptors of the same type on the interceptor chain

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-1418.
------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.1)
                   2.0.5
         Assignee: Daniel Kulp


Add a uniqueId flag to the constructors.

> 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
>            Assignee: Daniel Kulp
>            Priority: Minor
>             Fix For: 2.0.5
>
>
> 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.


[jira] Updated: (CXF-1418) Problem having multiple interceptors of the same type on the interceptor chain

Posted by "aaron pieper (JIRA)" <ji...@apache.org>.
     [ 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.