[cdi-dev] Should javax.enterprise.inject.Produces be inherited?

Tue Sep 13 09:15:51 EDT 2016

Tomas,

Yep, I'm not trying to say there is already inheritance.  What I'm trying to say is that the produces annotation should be inherited, making it so that there is inheritance now.

John

________________________________
From: Tomas Remes <tremes at redhat.com>
Sent: Tuesday, September 13, 2016 8:51 AM
To: John Ament
Cc: cdi-dev
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?

Hi John,

Please note there is no such inheritance of scope for producer method in this case in the Weld. I added test https://github.com/weld/core/commit/77f6916b55882a81d5fb33313d2e58806605bb17
[https://avatars2.githubusercontent.com/u/924640?v=3&s=200]<https://github.com/weld/core/commit/77f6916b55882a81d5fb33313d2e58806605bb17>

Test scope of alternative producer is not inherited. · weld/core at 77f6916<https://github.com/weld/core/commit/77f6916b55882a81d5fb33313d2e58806605bb17>
github.com
core - Weld, including integrations for Servlet containers and Java SE, examples and documentation

Thanks
Tom

----- Original Message -----
From: "John Ament" <john.ament at spartasystems.com>
To: "Emily Jiang" <EMIJIANG at uk.ibm.com>
Cc: "cdi-dev" <cdi-dev at lists.jboss.org>
Sent: Tuesday, September 13, 2016 12:33:33 PM
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?

Emily,

Just want to make sure I follow. Are you saying this because right now it is required that you add @Produces to the overridden method?

I don't realistically see a scenario where you would override the method and not add produces. This method is intended to be called by the container.

John

From: Emily Jiang <EMIJIANG at uk.ibm.com>
Sent: Tuesday, September 13, 2016 4:37 AM
To: John Ament
Cc: Matej Novotny; Mark Struberg; cdi-dev
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
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 at uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM at IBMGB

From: John Ament <john.ament at spartasystems.com>
To: Matej Novotny <manovotn at redhat.com>, Mark Struberg <struberg at yahoo.de>
Cc: Emily Jiang/UK/IBM at IBMGB, cdi-dev <cdi-dev at 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 at 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 at 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 at yahoo.de>
> To: "John Ament" <john.ament at spartasystems.com>, "Emily Jiang" <EMIJIANG at uk.ibm.com>
> Cc: "cdi-dev" <cdi-dev at 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 at 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 at 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 at uk.ibm.com
> >Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> >
> >
> >
> >
> >From: John Ament <john.ament at spartasystems.com>
> >To: cdi-dev <cdi-dev at lists.jboss.org>
> >Date: 11/09/2016 20:04
> >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by: cdi-dev-bounces at 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 at 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 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.
> >
> >
> _______________________________________________
> 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.
>

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 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.

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 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

________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160913/de2f9e23/attachment-0001.html 