Problem with mulitple custom interceptors and passivation
---------------------------------------------------------

                 Key: OWB-483
                 URL: https://issues.apache.org/jira/browse/OWB-483
             Project: OpenWebBeans
          Issue Type: Bug
          Components: Interceptor and Decorators
            Reporter: David Jencks
            Assignee: Gurkan Erdogdu
         Attachments: OWB-483-getId.patch

I ran into this problem running the tck in geronimo-owb running the tests 
org.jboss.jsr299.tck.tests.interceptors.definition.custom.*

The code causing problems is:
{code}
public class AfterBeanDiscoveryObserver implements Extension
{
   public static final CustomInterceptorImplementation 
POST_CONSTRUCT_INTERCEPTOR = new 
CustomInterceptorImplementation(POST_CONSTRUCT);
   public static final CustomInterceptorImplementation PRE_DESTROY_INTERCEPTOR 
= new CustomInterceptorImplementation(PRE_DESTROY);
   public static final CustomInterceptorImplementation 
POST_ACTIVATE_INTERCEPTOR = new CustomInterceptorImplementation(POST_ACTIVATE);
   public static final CustomInterceptorImplementation 
PRE_PASSIVATE_INTERCEPTOR = new CustomInterceptorImplementation(PRE_PASSIVATE);
   public static final CustomInterceptorImplementation 
AROUND_INVOKE_INTERCEPTOR = new CustomInterceptorImplementation(AROUND_INVOKE);
   public static final CustomInterceptorImplementation 
AROUND_TIMEOUT_INTERCEPTOR = new 
CustomInterceptorImplementation(AROUND_TIMEOUT);
   
   public void addInterceptors(@Observes AfterBeanDiscovery event) {
      event.addBean(POST_CONSTRUCT_INTERCEPTOR);
      event.addBean(PRE_DESTROY_INTERCEPTOR);
      event.addBean(POST_ACTIVATE_INTERCEPTOR);
      event.addBean(PRE_PASSIVATE_INTERCEPTOR);
      event.addBean(AROUND_INVOKE_INTERCEPTOR);
      event.addBean(AROUND_TIMEOUT_INTERCEPTOR);
   }
}
{code}

which adds a lot of interceptor instances all of the same class, just 
configured differently.

In the current geronimo-owb integration this fails with the second interceptor 
with

{code}
2010-10-24 10:22:27,634 ERROR [BeansDeployer] 
org.apache.webbeans.exception.definition.DuplicateDefinitionException: 
PassivationCapable bean id is not unique: INTERCEPTOR#class 
org.jboss.jsr299.tck.tests.interceptors.definition.custom.SimpleInterceptorWithoutAnnotations#
 bean:WebBeans Interceptor with class : 
[org.jboss.jsr299.tck.tests.interceptors.definition.custom.SimpleInterceptorWithoutAnnotations]
        at 
org.apache.webbeans.container.BeanManagerImpl.addPassivationInfo(BeanManagerImpl.java:356)
        at 
org.apache.webbeans.container.BeanManagerImpl.addInterceptor(BeanManagerImpl.java:520)
        at 
org.apache.webbeans.portable.events.discovery.AfterBeanDiscoveryImpl.addBean(AfterBeanDiscoveryImpl.java:105)
        at 
org.jboss.jsr299.tck.tests.interceptors.definition.custom.AfterBeanDiscoveryObserver.addInterceptors(AfterBeanDiscoveryObserver.java:42)
{code}

--analysis--

The addPassivationInfo method checks for bean.getId() to be non-null and tries 
to add it if non-null.  The comments around getId() and the naming of the 
cached ID as passivationId seem to  indicate that this should be non-null only 
if the bean can be passivated.  However, there's a method 
isPassivationCapable() that is not consulted here.  in fact for the 
interceptors in question, isPassivationCapable() returns false, and checking it 
makes the test pass.

However, the implementation of isPassivationCapable for interceptors is

{code}
    @Override
    public boolean isPassivationCapable()
    {
        return this.delegateBean.isPassivationCapable();
    }
{code}
in OpenWebBeansInterceptor.  I'm not sure what the delegateBean might end up 
being, but this suggests that some custom interceptors could in fact be 
passivationCapable.  However, the bean.getId() method doesn't appear to take 
account of the interceptors object identity in any way. If the delegate bean in 
this test was passivation capable the same error would occur as I have 
experienced.

In addition, the getId() method loops through this.implQualifiers.  I wonder if 
this is correct since this can also be accessed through getQualifiers() which 
is overridden in CustomInterceptor to delegate to the Interceptor instance (its 
overridden in other subclasses too).  While in this particular test this 
returns an empty set, thus failing to disambiguate the Interceptor instances, 
it might be more correct in general.

I will attach a patch checking isPassivationCapable in getId()  which makes the 
tck test pass for me.





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

Reply via email to