From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.

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&gt; To: "Emily Jiang" <emijiang6(a)googlemail.com&gt; Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org&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&gt; To: "cdi-dev" <cdi-dev(a)lists.jboss.org&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 > 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 -- Thanks Emily ================= Emily Jiang ejiang(a)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. -- Tomas Remes _______________________________________________ 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.

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

Hi, Emily before we delve into questions regarding spec clarification, I have two questions for you :) 1) What is the point of disabling @Specialized bean(be it with @Veto or @Alternative) when you have no other @Specialized bean to take its place? - this use case just feels....weird at best? - to me it seems rather unusual, I guess you need to achieve different behavior in two cases - that's what you can do with 2 @Spec beans 2) Isn't there always a way around to achieve what you are aiming for? - enabling it app-wise with @Priority or using two @Specialized beans with additional qualifiers? - this way you are still moving within boundaries of current spec and can achieve the same goal - could you, please, give me a use-case where your scenario is absolutely necessary? Matej ----- Original Message ----- From: "Emily Jiang" <emijiang6(a)googlemail.com&gt; To: "Martin Kouba" <mkouba(a)redhat.com&gt; Cc: "Matej Novotny" <manovotn(a)redhat.com&gt;, "cdi-dev" < cdi-dev(a)lists.jboss.org&gt; Sent: Monday, November 23, 2015 11:30:54 AM Subject: Re: [cdi-dev] Clarification on 4.3 Specialization 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(a)redhat.com&gt; 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(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 > -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org