On Mon, Nov 23, 2015 at 11:13 AM, Matej Novotny <manovotn@redhat.com> wrote:

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@googlemail.com>
To: "Martin Kouba" <mkouba@redhat.com>
Cc: "Matej Novotny" <manovotn@redhat.com>, "cdi-dev" <cdi-dev@lists.jboss.org>
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@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@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@redhat.com <mailto:tremes@redhat.com>>
>> To: "Emily Jiang" <emijiang6@googlemail.com
>> <mailto:emijiang6@googlemail.com>>
>> Cc: "cdi-dev" <cdi-dev@lists.jboss.org <mailto:
>> cdi-dev@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@googlemail.com
>> <mailto:emijiang6@googlemail.com>>
>> To: "cdi-dev" <cdi-dev@lists.jboss.org <mailto:
>> cdi-dev@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@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@apache.org <mailto:ejiang@apache.org>
>>
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org <mailto:ejiang@apache.org>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev@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@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@apache.org <mailto:ejiang@apache.org>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> 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.
>>
>>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>

--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org

Thanks
Emily
=================
Emily Jiang
ejiang@apache.org