[cdi-dev] Clarification on 4.3 Specialization
Martin Kouba
mkouba at redhat.com
Mon Nov 23 05:06:35 EST 2015
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
More information about the cdi-dev
mailing list