[cdi-dev] Clarification on 4.3 Specialization
Emily Jiang
emijiang6 at googlemail.com
Mon Nov 23 06:33:21 EST 2015
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.
On Mon, Nov 23, 2015 at 11:13 AM, Matej Novotny <manovotn at 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 at googlemail.com>
> To: "Martin Kouba" <mkouba at redhat.com>
> Cc: "Matej Novotny" <manovotn at redhat.com>, "cdi-dev" <
> cdi-dev at 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 at 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 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
> >
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>
--
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20151123/22df8fd6/attachment-0001.html
More information about the cdi-dev
mailing list