You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2010/10/25 00:00:23 UTC
[jira] Created: (OWB-483) Problem with mulitple custom interceptors
and passivation
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.
[jira] Updated: (OWB-483) Problem with mulitple custom interceptors
and passivation
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jencks updated OWB-483:
-----------------------------
Attachment: OWB-483-getId.patch
check isPassivationCapable in getId
> 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924480#action_12924480 ]
David Jencks commented on OWB-483:
----------------------------------
I was mistaken, these tests are not excluded. I will try to figure out why they pass standalone.
> 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.
[jira] Resolved: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924483#action_12924483 ]
Mark Struberg commented on OWB-483:
-----------------------------------
Hi David!
Please also consult https://jira.jboss.org/browse/CDITCK if you find any excluded TCK test in OWB. This might most likely be an error in the TCK itself. For what I remember all the excluded tests are really wrong in the TCK itself.
> 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925325#action_12925325 ]
Mark Struberg commented on OWB-483:
-----------------------------------
Please note that any Interceptor instance is per spec definition a @Dependent scoped instance and thus gets passivated along with the passivatable bean. So the interceptor bean really needs a passivationId if it is designed to get attached to a Serializable bean.
> 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "Gurkan Erdogdu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925333#action_12925333 ]
Gurkan Erdogdu commented on OWB-483:
------------------------------------
I think that this section is a bit misunderstanding point of the specification. Passivation is there just solely for saving bean current instance to secondary place. Dependent beans need not get a passivation id, because when owner bean is serialized, it is reconstructed on other side using its passivation id. On that side, interceptors has already attached to that bean.
> 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925454#action_12925454 ]
David Jencks commented on OWB-483:
----------------------------------
That makes sense:-). However, does this mean that my original patch that makes getId() return null unless the bean is passivationCapable is reasonable? It broke 2 or 3 tck tests which might mean that either isPassivationCapable is not always correct or some other part of serialization isn't working quite right.
> 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.
[jira] Commented: (OWB-483) Problem with mulitple custom
interceptors and passivation
Posted by "David Jencks (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924454#action_12924454 ]
David Jencks commented on OWB-483:
----------------------------------
I've discovered that the tests in question are excluded in the OWB tck configuration, and that beans may be serialized even if they are not passivation capable, so my patch is definitely wrong. I'd still like to know what's wrong with the test's attempt to set up multiple interceptors using the same class.
> 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.