[
https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved OWB-483.
------------------------------
Resolution: Fixed
This problem is resolved by the changes Gerkan made for OWB-484. I'm still
curious whether custom interceptors can be attached to a passivation capable
bean and what will happen in this scenario if they are. I think the duplicate
ID problem will recur.
> 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.
