<div dir="ltr"><div><div><div></div>This is a test application and test this spec section 4.3. I would like to see the application behaves the same on both Weld and OWB.<br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 11:13 AM, Matej Novotny <span dir="ltr"><<a href="mailto:manovotn@redhat.com" target="_blank">manovotn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Emily<br>
<br>
before we delve into questions regarding spec clarification, I have two questions for you :)<br>
<br>
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?<br>
- this use case just feels....weird at best?<br>
- 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<br>
<br>
2) Isn't there always a way around to achieve what you are aiming for?<br>
- enabling it app-wise with @Priority or using two @Specialized beans with additional qualifiers?<br>
- this way you are still moving within boundaries of current spec and can achieve the same goal<br>
- could you, please, give me a use-case where your scenario is absolutely necessary?<br>
<span class="im HOEnZb"><br>
Matej<br>
<br>
----- Original Message -----<br>
</span><div class="HOEnZb"><div class="h5">From: "Emily Jiang" <<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a>><br>
To: "Martin Kouba" <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>><br>
Cc: "Matej Novotny" <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>>, "cdi-dev" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
Sent: Monday, November 23, 2015 11:30:54 AM<br>
Subject: Re: [cdi-dev] Clarification on 4.3 Specialization<br>
<br>
Hi Martin,<br>
Although the spec does not enforce that @Specialized must be used in<br>
conjunction with @Alternative , I would like to unify the understanding of<br>
what the spec behavior of @Specialized on an disabled bean is.<br>
<br>
Thanks<br>
Emily<br>
<br>
On Mon, Nov 23, 2015 at 10:06 AM, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> wrote:<br>
<br>
> Hi Emily,<br>
><br>
> the problem is Specialization is not defined per bean archive but per<br>
> application. A bean is either specialized or not. Note that specialization<br>
> is not tied to alternatives.<br>
><br>
> WRT your use-case: the specializing bean should be enabled globally or in<br>
> each bean archive which is using the specialized bean.<br>
><br>
> Martin<br>
><br>
> Dne 23.11.2015 v 10:54 Emily Jiang napsal(a):<br>
><br>
>> Thank you Tom and Matej for your response!<br>
>> The alternative was enabled in the archive beans-xml-modified.jar, but<br>
>> it is not enabled in the archive beans-xml-modified2.jar. The issue is<br>
>> not with alternative but with Specialized.<br>
>><br>
>> At the moment, Weld specialized is effective even if itself is not<br>
>> enabled, which is not desirable because it disables other bean but<br>
>> itself is not enabled. As a consequence, this causes deployment error.<br>
>><br>
>> The CDI 1.2 section 4.3 spec says:<br>
>> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled<br>
>> beans”, specializes<br>
>> a second bean, we can be certain that the second bean is never<br>
>> instantiated or called by the<br>
>> container. Even if the second bean defines a producer or observer<br>
>> method, the method will never<br>
>> be called.<br>
>><br>
>> It is true the above sentence comments about an enabled bean. It hits an<br>
>> disabled bean should not specialize a second bean. If you guys think it<br>
>> is unclear, can we update the spec to clarify this scenario?<br>
>><br>
>> By the way, OWB and Weld behave differently (Weld thinks a disabled bean<br>
>> still specializes a second bean while OWB thinks a disabled bean does<br>
>> NOT specialize a second bean). This is something we can leave to<br>
>> implementation. We should spec it!<br>
>><br>
>> On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a><br>
>> <mailto:<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>>> wrote:<br>
>><br>
>> Hello Emily<br>
>><br>
>> I agree with Tom. In your case, specialized producer is enabled (via<br>
>> beans.xml) although only per bean archive.<br>
>><br>
>><br>
>> And about this:<br>
>> >>From Weld's perspective, any bean annotated with @Specialized<br>
>> disables a second bean regardless whether itself is active or not.<br>
>><br>
>> It is true, however the spec doesn't define how does a @Specialized<br>
>> bean behave when it is disabled (or at least I haven't found that<br>
>> bit).<br>
>> So this leaves it up to implementation and I can't really see a<br>
>> problem with it. Why would you create a @Specialized bean and<br>
>> disable it afterwards (with no other @Specialized and/or<br>
>> @Alternative active)?<br>
>><br>
>><br>
>> Matej<br>
>><br>
>> ----- Original Message -----<br>
>> From: "Tomas Remes" <<a href="mailto:tremes@redhat.com">tremes@redhat.com</a> <mailto:<a href="mailto:tremes@redhat.com">tremes@redhat.com</a>>><br>
>> To: "Emily Jiang" <<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a><br>
>> <mailto:<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a>>><br>
>> Cc: "cdi-dev" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>>><br>
>> Sent: Monday, November 23, 2015 8:33:44 AM<br>
>> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization<br>
>><br>
>><br>
>> Hi Emily,<br>
>><br>
>> I am not sure I follow. What is disabled?<br>
>> AlternativeCounterProducerModified? I can see<br>
>> AlternativeCounterProducerModified is enabled in beans.xml of the<br>
>> given bean archive and it means it is selected alternative only per<br>
>> the bean archive. So I can't see any problem (or maybe I don't fully<br>
>> understand).<br>
>><br>
>> Tom<br>
>><br>
>> ----- Original Message -----<br>
>> From: "Emily Jiang" <<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a><br>
>> <mailto:<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a>>><br>
>> To: "cdi-dev" <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>>><br>
>> Sent: Sunday, November 22, 2015 10:42:29 PM<br>
>> Subject: Re: [cdi-dev] Clarification on 4.3 Specialization<br>
>><br>
>> any thoughts?<br>
>><br>
>> Should a bean with @Specialize disable a bean even if it is disabled<br>
>> itself?<br>
>><br>
>> On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang <<br>
>> <a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a> <mailto:<a href="mailto:emijiang6@googlemail.com">emijiang6@googlemail.com</a>> > wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> I have an application containing two wars.<br>
>><br>
>> testDiffBDA.war<br>
>> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class<br>
>><br>
>> @Inject CounterProducerConsumerModified2 bean;<br>
>><br>
>><br>
>> beans-xml-modified2.jar<br>
>> containing one bean and an empty-ish beans.xml :<br>
>> @Inject@CounterModifiedQualifier String modifiedProducer;<br>
>><br>
>> beans-xml-modified.jar.jar<br>
>> CounterModifiedQualifier (the interface)<br>
>> CounterProducerModified (the bean implementing that interface)<br>
>> AlternativeCounterProducerModified (an alternative specialized bean)<br>
>> beans.xml<br>
>> <alternatives><br>
>><br>
>> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class><br>
>> </alternatives><br>
>><br>
>> My application failed deployment with the error on Weld but worked<br>
>> on OpenWebBeans<br>
>><br>
>> [ERROR ] CWWKZ0004E: An exception occurred while starting the<br>
>> application testDiffBDA. The exception message was:<br>
>> com.ibm.ws.container.service.state.StateChangeException:<br>
>> org.jboss.weld.exceptions.DeploymentException: WELD-001408:<br>
>> Unsatisfied dependencies for type String with qualifiers<br>
>> @CounterModifiedQualifier<br>
>> at injection point [BackedAnnotatedField] @Inject<br>
>> @CounterModifiedQualifier<br>
>><br>
>> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer<br>
>> at<br>
>><br>
>> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)<br>
>> --<br>
>><br>
>><br>
>> After further investigation and talking to Martin from Weld, the<br>
>> error was caused due to the fact of<br>
>> AlternativeCounterProducerModified disabling the<br>
>> CounterProducerModified bean but itself is not enabled in the jar of<br>
>> beans-xml-modified2.jar. Therefore, no producer is active to produce<br>
>> a bean with the qualifier CounterModifiedQualifier.<br>
>><br>
>> >From Weld's perspective, any bean annotated with @Specialized<br>
>> disables a second bean regardless whether itself is active or not.<br>
>><br>
>> My understanding is that the specialized should only take effect if<br>
>> itself is enabled. Otherwise, we run into the situation of where the<br>
>> specialized bean is not enabled but it disabled another bean. To me,<br>
>> it is wrong.<br>
>><br>
>><br>
>> I also checked the spec:<br>
>> @Alternative @Specializes<br>
>> public class MockAsynchronousService extends AsynchronousService {<br>
>> ...<br>
>> }<br>
>> When an enabled bean, as defined in Section 5.1.2, “Enabled and<br>
>> disabled beans”, specializes<br>
>> a second bean, we can be certain that the second bean is never<br>
>> instantiated or called by the<br>
>> container. Even if the second bean defines a producer or observer<br>
>> method, the method will never<br>
>> be called.<br>
>><br>
>> The spec says only an enabled bean can specialize a second bean. I<br>
>> would like to know what other people think.<br>
>><br>
>><br>
>> Thanks<br>
>> Emily<br>
>> =================<br>
>> Emily Jiang<br>
>> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a> <mailto:<a href="mailto:ejiang@apache.org">ejiang@apache.org</a>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Thanks<br>
>> Emily<br>
>> =================<br>
>> Emily Jiang<br>
>> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a> <mailto:<a href="mailto:ejiang@apache.org">ejiang@apache.org</a>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses<br>
>> the code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
>> ideas provided on this list, the provider waives all patent and<br>
>> other intellectual property rights inherent in such information.<br>
>><br>
>> --<br>
>> Tomas Remes<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses<br>
>> the code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other<br>
>> ideas provided on this list, the provider waives all patent and<br>
>> other intellectual property rights inherent in such information.<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Thanks<br>
>> Emily<br>
>> =================<br>
>> Emily Jiang<br>
>> <a href="mailto:ejiang@apache.org">ejiang@apache.org</a> <mailto:<a href="mailto:ejiang@apache.org">ejiang@apache.org</a>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses the<br>
>> code under the Apache License, Version 2 (<br>
>> <a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other<br>
>> intellectual property rights inherent in such information.<br>
>><br>
>><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
><br>
<br>
<br>
<br>
--<br>
Thanks<br>
Emily<br>
=================<br>
Emily Jiang<br>
<a href="mailto:ejiang@apache.org">ejiang@apache.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Thanks<br>Emily<br>=================<br>Emily Jiang<br><a href="mailto:ejiang@apache.org" target="_blank">ejiang@apache.org</a><br></div>
</div>