[cdi-dev] [JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

[Mark Struberg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134058#comment-13134058 ] 

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