]
Antoine Sabot-Durand commented on CDI-574:
------------------------------------------
Guys. I already gave my opinion during last meeting:
* alternatives can be selected at bean archive level
* specialization is global
* If an alternative is selected in at least one bean archive the bean is enabled.
* If a specializes bean is enabled, the bean that was specialized is disabled
There is no ambiguity here.
I agree that it's not an intuitive behavior but now it's written in black on white
in the spec.
On the other hand I find the topic very "corner-case-ish" : the use case
described suppose that I own the corresponding bean archive so I can change their config
(or use {{@Priority}}) to obtain the expected behavior.
Working on a global config proposal (as we spoke during face to face) would more helpful
than continuing this thread IMO.
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.