[cdi-dev] Clarification on 4.3 Specialization

Emily Jiang emijiang6 at googlemail.com
Sun Nov 22 16:42:29 EST 2015


any thoughts?

Should a bean with @Specialize disable a bean even if it is disabled itself?

On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang <emijiang6 at googlemail.com>
wrote:

>
> 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
>
> [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)
> --
>
>
> 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.
>
>
> I also checked the spec:
> @Alternative @Specializes
> public class MockAsynchronousService extends AsynchronousService {
> ...
> }
> 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. I would
> like to know what other people think.
>
>
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151122/262c87cc/attachment.html 


More information about the cdi-dev mailing list