First of all, the subject line suggests
the produces should be inherited under all conditions. Anyway, after your
explanation, I think this suggestion contradicts with spec and breaks backward
compatibility. In the cdi 1.2/cdi 2.0 spec,
The only way one bean can completely override a second
bean at all injection points is if it implements all the bean types and
declares all the qualifiers of the second bean. However, if the second
bean declares a producer method or observer method, then even this is not
enough to ensure that the second bean is never called!
To help prevent developer error, the first bean may:
- directly extend the bean class of the second bean, or
- directly override the producer method, in the case
that the second bean is a producer method, and then
explicitly
declare that it specializes the second bean.
After this suggestion, the above sentence
is not true any more.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Development Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From:
John Ament <john.ament@spartasystems.com>
To:
Matej Novotny <manovotn@redhat.com>,
Mark Struberg <struberg@yahoo.de>
Cc:
Emily Jiang/UK/IBM@IBMGB,
cdi-dev <cdi-dev@lists.jboss.org>
Date:
12/09/2016 13:31
Subject:
Re: [cdi-dev]
Should javax.enterprise.inject.Produces be inherited?
Sent by:
cdi-dev-bounces@lists.jboss.org
@Matej - Yes, that would be consistent
with what I was seeing as well.
@Mark - Are you thinking about decorators
and not alternatives? See also [1]
Really the goal here is to substitute the
bean, but not just the provided bean the producer method that it exposes.
It seems to work as I would expect it in weld (as mentioned), when
I add @Produces to the method, it overrides the base class's producer method.
No ambiguous resolutions, it just works properly.
Realistically, this is all an experiment
to see if I can provide spring boot like default configurations (beans,
config values, etc) in a framework, and override them as an application
developer.
[1]: http://docs.jboss.org/cdi/spec/2.0.EDR2/cdi-spec.html#alternatives
From: Matej Novotny <manovotn@redhat.com>
Sent: Monday, September 12, 2016 3:28 AM
To: Mark Struberg
Cc: John Ament; Emily Jiang; cdi-dev
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Hi all,
I did some testing (with Weld) and it seems the scope IS inherited when
you use @Alternative.
However it IS NOT inherited when you use @Specialized.
Not yet sure if this is intended or anyhow spec-defined, just stating facts.
Matej
----- Original Message -----
> From: "Mark Struberg" <struberg@yahoo.de>
> To: "John Ament" <john.ament@spartasystems.com>, "Emily
Jiang" <EMIJIANG@uk.ibm.com>
> Cc: "cdi-dev" <cdi-dev@lists.jboss.org>
> Sent: Monday, September 12, 2016 8:00:55 AM
> Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be
inherited?
>
>
>
> > Right now inheritance of managed beans is itself problematic,
as
>
> > injecting the base class can cause these ambiguous resolutions.
>
> Yes, that's why we originally introduced @Typed.
>
>
>
> Your sample wont work as an Alternative as it extends a concrete class
and
> doesn't implement any interface.
> Did you mean @Specializes?
> Note that with @Alternative you won't make the original producer go
away.You
> would also need to add @Alternative to the producer method imo. The
rules
> for making an alternative producer method are really a bit confusing
;) I
> think the most portable way is to annotate both the class and the
producer
> method with @Alternative.
>
>
> LieGrue,
> strub
>
>
> On Monday, 12 September 2016, 0:57, John Ament <john.ament@spartasystems.com>
> wrote:
> >
> >Hi Emily,
> >
> >
> >I disagree, at least it doesn't add any new ambiguous injections.
The
> >use-case is specifically to Specialized/Alternative beans. Right
now
> >inheritance of managed beans is itself problematic, as injecting
the base
> >class can cause these ambiguous resolutions.
> >
> >
> >The example I sent out actually works correctly (in weld at least),
really
> >my propose is to remove the need to have Produces a second time
and update
> >the spec to clarify what happens here (FWIW, I don't believe the
case is
> >currently described in the spec), hopefully to say that qualifiers
and
> >scopes from the base method remain in effect, unless explicitly
overridden.
> >
> >
> >John
> >
> >
> >
> >________________________________
> >
> >From: Emily Jiang <EMIJIANG@uk.ibm.com>
> >Sent: Sunday, September 11, 2016 5:59 PM
> >To: John Ament
> >Cc: cdi-dev
> >Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces
be inherited?
> >
> >I think this is very problematic as you will get
> >AmbiguousResolutionException all the time once we introduce this
> >inheritance.
> >
> >Many thanks,
> >Emily
> >===========================
> >Emily Jiang
> >WebSphere Application Server, CDI Development Lead
> >
> >MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> >Phone: +44 (0)1962 816278 Internal: 246278
> >
> >Email: emijiang@uk.ibm.com
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From: John Ament <john.ament@spartasystems.com>
> >To: cdi-dev <cdi-dev@lists.jboss.org>
> >Date: 11/09/2016 20:04
> >Subject: [cdi-dev] Should javax.enterprise.inject.Produces
be
> >inherited?
> >Sent by: cdi-dev-bounces@lists.jboss.org
> >>________________________________
> >
> >
> >
> >All,
> >
> >I was just thinking about alternatives and producer methods. Suppose
I have
> >the following bean:
> >
> >@ApplicationScoped
> >public class Boop {
> >
> > @Produces
> > @ApplicationScoped
> > public Simpler makeSimpler() {
> > return new Simpler("Boop");
> > }
> >}
> >
> >If I want to override the producer method, I need to declare fully:
> >
> >@Alternative
> >@Priority(100)
> >@ApplicationScoped
> >public class BoopAlternative extends Boop{
> > @Override
> > @Produces
> > public Simpler makeSimpler() {
> > return new Simpler("Boop2");
> > }
> >}
> >
> >For some reason, scopes are inherited, but the produces annotation
is not.
> >At least in the case of a producer method, it seems like it would
be
> >useful for @Produces to be inherited as well.
> >
> >John
> >
> >________________________________
> > NOTICE: This e-mail message and any attachments may contain confidential,
> > proprietary, and/or privileged information which should be treated
> > accordingly. If you are not the intended recipient, please notify
the
> > sender immediately by return e-mail, delete this message, and
destroy all
> > physical and electronic copies. Thank you.
> > _______________________________________________
> >cdi-dev mailing list
> >cdi-dev@lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev
Info Page - JBoss Developer
lists.jboss.org
List to discuss the development
of CDI (the specification) To see the collection of prior postings to the
list, visit the cdi-dev Archives. |
> >
> >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.
> >cdi-dev Info Page - JBoss Developer
> >lists.jboss.org
> >List to discuss the development of CDI (the specification) To
see the
> >collection of prior postings to the list, visit the cdi-dev Archives.
> >
> >
> >Unless stated otherwise above:
> >IBM United Kingdom Limited - Registered in England and Wales with
number
> >741598.
> >Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU
> >
> >
> >
> >________________________________
> > NOTICE: This e-mail message and any attachments may contain confidential,
> > proprietary, and/or privileged information which should be treated
> > accordingly. If you are not the intended recipient, please notify
the
> > sender immediately by return e-mail, delete this message, and
destroy all
> > physical and electronic copies. Thank you.
> >
> >_______________________________________________
> >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.
> >
> >
> _______________________________________________
> 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.
>
NOTICE: This e-mail message and any attachments may contain
confidential, proprietary, and/or privileged information which should be
treated accordingly. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this message, and destroy
all physical and electronic copies. Thank you. _______________________________________________
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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU