Re: [cdi-dev] Clarification on 4.3 Specialization

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(a)redhat.com > <mailto:manovotn@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(a)redhat.com <mailto:tremes@redhat.com>> > To: "Emily Jiang" <emijiang6(a)googlemail.com > <mailto:emijiang6@googlemail.com>> > Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org <mailto: > cdi-dev(a)lists.jboss.org&gt;&gt; > 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(a)googlemail.com > <mailto:emijiang6@googlemail.com>> > To: "cdi-dev" <cdi-dev(a)lists.jboss.org <mailto: > cdi-dev(a)lists.jboss.org&gt;&gt; > 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(a)googlemail.com <mailto:emijiang6@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@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(a)apache.org <mailto:ejiang@apache.org> > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang(a)apache.org <mailto:ejiang@apache.org> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@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(a)lists.jboss.org <mailto:cdi-dev@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(a)apache.org <mailto:ejiang@apache.org> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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