[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
.bq Soon as you enable specializing bean in one archive it disables the original bean.
That means your app will not even start? And even if, there is no way it could run because in the other jar it would permanently blow up with BeanNotFound or whatever...
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
You both ignored my question: what happens with an observer in there? How to disable them effectively? In Weld it is simply not possible it seems.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-574:
-----------------------------------
bq. The specializing bean is enabled in one bean archive and disabled in the second bean archive. And you will probably get unsatisfied dependency because the specialized bean is completely ignored.
+1, I agree with Martin.
As clumsy as it may sounds at first, it makes sense. Soon as you enable specializing bean in one archive it disables the original bean. So much for specialization, it is not limited to archives. Then there is @Alternative - enabling it (talking about different archive as per example given) will allow the @Specialized bean to work, not having it enabled will attempt to use the original bean which is disabled hence resulting in an error (unsatisfied dep. in this case).
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba edited comment on CDI-574 at 11/26/15 4:42 AM:
------------------------------------------------------------
bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled...
In this particular use-case the specializing bean is enabled in one bean archive and disabled in the second bean archive.
was (Author: mkouba):
bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled...
In this particular use-case the specialized bean is enabled in one bean archive and disabled in the second bean archive.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-574:
----------------------------------
bq. What is the expected outcome?
The specializing bean is enabled in one bean archive and disabled in the second bean archive. And you will probably get unsatisfied dependency because the specialized bean is completely ignored.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
I agree that the spec is not perfectly accurate. And yes, OWB solves this black spot by merging beans.xml files internally. I am working with big CDI projects since 6 years and I _never_ had the urge to have a bean enabled in one jar and disabled in another. Nor does any of the 5k++ conference listeners I asked in the many talks I gave around the globe. Actually the per-jar enablement of alternatives and interceptors is the No1 most-hated behaviour of CDI ;)
Anyway, lets get back to the original question with @Alternative @Specializes (which is also a prominent example in the spec since CDI-1.0) and 2 jars where in 1 the alternative is enabled and in the other it isn't. What is the expected outcome?
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-574:
----------------------------------
bq. The inconsistency in Weld is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option)
Well, I would call it a spec inconsistency. One might argue that a jar inside WEB-INF/lib is a library and the spec states _"The Java EE module or library is a bean archive..."_. Also the spec *does not say anything about beans.xml merging* which is required if OWB interpretation is used. E.g. what happens if there are two libs inside WEB-INF/lib. One enables an alternative and the second does not and expects it to be disabled? It's a complicated topic. However, I think it's NOT fair to mark Weld interpretation as inconsistent if the correct behaviour is disputable.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-574 at 11/25/15 11:18 AM:
--------------------------------------------------------------
Imo OWB is spec conform as well. It's all a matter of how you interpret the term BDA in the CDI spec. The inconsistency in Weld is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not.
It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, .
was (Author: struberg):
No, this is imo an inconsistency in Weld. It is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not.
It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, .
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
No, this is imo an inconsistency in Weld. It is a direct consequence of Weld interpreting the term 'BDA' as per-jar (section 12 interpretation option) and not as per-module (section 5 interpretation option). See CDI-18 and other issues for the discussion. In OWB the alternative is 'per ee module' by default. So the whole EE module (e.g. a single WAR) either has the alternative enabled or not. And thus the whole specialized bean is enabled for the whole ee module or not. That way we are a.) much faster (as we don't need to check the invoker chain each proxy invocation) and b.) more consistent. EE-modules usually are 1:1 to ClassLoaders and BeanManagers. Thus for each BeanManager a bean is clearly either enabled or not.
It's an old story that the bda-per-jar interpretation is inconsistent within itself. How should that be solved? Will the observer method in the specialized away bean get invoked or not? What if I just add a SINGLE jar which don't have this Alternative enabled? Will the observer method then get invoked again? What about implicit bean archives? Those are almost always present, Just add a single slf4j api or whatever other util jar. In practice this will render disabling beans via specialisation useless. etc, .
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-574:
---------------------------------
This was discussed in Yesterday's cdi-dev chat: http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23...
The conclusion from Antoine: Weld complies with spec but OWB does not, even though the spec is not user friendly.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months