[cdi-dev] Clarification on 4.3 Specialization

Emily Jiang emijiang6 at googlemail.com
Mon Nov 23 05:30:54 EST 2015


Hi Martin,
Although the spec does not enforce that @Specialized must be used in
conjunction with @Alternative , I would like to unify the understanding of
what the spec behavior of @Specialized on an disabled bean is.

Thanks
Emily

On Mon, Nov 23, 2015 at 10:06 AM, Martin Kouba <mkouba at redhat.com> wrote:

> Hi Emily,
>
> the problem is Specialization is not defined per bean archive but per
> application. A bean is either specialized or not. Note that specialization
> is not tied to alternatives.
>
> WRT your use-case: the specializing bean should be enabled globally or in
> each bean archive which is using the specialized bean.
>
> Martin
>
> Dne 23.11.2015 v 10:54 Emily Jiang napsal(a):
>
>> Thank you Tom and Matej for your response!
>> The alternative was enabled in the archive beans-xml-modified.jar, but
>> it is not enabled in the archive beans-xml-modified2.jar. The issue is
>> not with alternative but with Specialized.
>>
>> At the moment, Weld specialized is effective even if itself is not
>> enabled, which is not desirable because it disables other bean but
>> itself is not enabled. As a consequence, this causes deployment error.
>>
>> The CDI 1.2 section 4.3  spec says:
>> 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.
>>
>> It is true the above sentence comments about an enabled bean. It hits an
>> disabled bean should not specialize a second bean. If you guys think it
>> is unclear, can we update the spec to clarify this scenario?
>>
>> By the way, OWB and Weld behave differently (Weld thinks a disabled bean
>> still specializes a second bean while OWB thinks a disabled bean does
>> NOT specialize a second bean). This is something we can leave to
>> implementation. We should spec it!
>>
>> On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny <manovotn at redhat.com
>> <mailto:manovotn at redhat.com>> wrote:
>>
>>     Hello Emily
>>
>>     I agree with Tom. In your case, specialized producer is enabled (via
>>     beans.xml) although only per bean archive.
>>
>>
>>     And about this:
>>     >>From Weld's perspective, any bean annotated with @Specialized
>> disables a second bean regardless whether itself is active or not.
>>
>>     It is true, however the spec doesn't define how does a @Specialized
>>     bean behave when it is disabled (or at least I haven't found that
>> bit).
>>     So this leaves it up to implementation and I can't really see a
>>     problem with it. Why would you create a @Specialized bean and
>>     disable it afterwards (with no other @Specialized and/or
>>     @Alternative active)?
>>
>>
>>     Matej
>>
>>     ----- Original Message -----
>>     From: "Tomas Remes" <tremes at redhat.com <mailto:tremes at redhat.com>>
>>     To: "Emily Jiang" <emijiang6 at googlemail.com
>>     <mailto:emijiang6 at googlemail.com>>
>>     Cc: "cdi-dev" <cdi-dev at lists.jboss.org <mailto:
>> cdi-dev at lists.jboss.org>>
>>     Sent: Monday, November 23, 2015 8:33:44 AM
>>     Subject: Re: [cdi-dev] Clarification on 4.3 Specialization
>>
>>
>>     Hi Emily,
>>
>>     I am not sure I follow. What is disabled?
>>     AlternativeCounterProducerModified? I can see
>>     AlternativeCounterProducerModified is enabled in beans.xml of the
>>     given bean archive and it means it is selected alternative only per
>>     the bean archive. So I can't see any problem (or maybe I don't fully
>>     understand).
>>
>>     Tom
>>
>>     ----- Original Message -----
>>     From: "Emily Jiang" <emijiang6 at googlemail.com
>>     <mailto:emijiang6 at googlemail.com>>
>>     To: "cdi-dev" <cdi-dev at lists.jboss.org <mailto:
>> cdi-dev at lists.jboss.org>>
>>     Sent: Sunday, November 22, 2015 10:42:29 PM
>>     Subject: Re: [cdi-dev] Clarification on 4.3 Specialization
>>
>>     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 <mailto: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 <mailto:ejiang at apache.org>
>>
>>
>>
>>     --
>>     Thanks
>>     Emily
>>     =================
>>     Emily Jiang
>>     ejiang at apache.org <mailto:ejiang at apache.org>
>>
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>     Note that for all code provided on this list, the provider licenses
>>     the code under the Apache License, Version 2
>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>     ideas provided on this list, the provider waives all patent and
>>     other intellectual property rights inherent in such information.
>>
>>     --
>>     Tomas Remes
>>
>>
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>     Note that for all code provided on this list, the provider licenses
>>     the code under the Apache License, Version 2
>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>     ideas provided on this list, the provider waives all patent and
>>     other intellectual property rights inherent in such information.
>>
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang at apache.org <mailto:ejiang at apache.org>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (
>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>



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


More information about the cdi-dev mailing list