Should javax.enterprise.inject.Produces be inherited?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Should javax.enterprise.inject.Produces be inherited?

John Ament

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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Emily Jiang
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        John Ament <[hidden email]>
To:        cdi-dev <[hidden email]>
Date:        11/09/2016 20:04
Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        [hidden email]




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
[hidden email]
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

_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

John Ament

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 <[hidden email]>
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        John Ament <[hidden email]>
To:        cdi-dev <[hidden email]>
Date:        11/09/2016 20:04
Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        [hidden email]




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
[hidden email]
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.
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Mark Struberg


> 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 <[hidden email]> 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 <[hidden email]>
>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: [hidden email]
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From:        John Ament <[hidden email]>
>To:        cdi-dev <[hidden email]>
>Date:        11/09/2016 20:04
>Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
>Sent by:        [hidden email]
>>________________________________
>
>
>
>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
>[hidden email]
>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 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
>[hidden email]
>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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Matej Novotny
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From:        John Ament <[hidden email]>
> >To:        cdi-dev <[hidden email]>
> >Date:        11/09/2016 20:04
> >Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by:        [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> >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 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
> >[hidden email]
> >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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

John Ament

@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From:        John Ament <[hidden email]>
> >To:        cdi-dev <[hidden email]>
> >Date:        11/09/2016 20:04
> >Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by:        [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
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
> >[hidden email]
> >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
> [hidden email]
> 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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Emily Jiang
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        John Ament <[hidden email]>
To:        Matej Novotny <[hidden email]>, Mark Struberg <[hidden email]>
Cc:        Emily Jiang/UK/IBM@IBMGB, cdi-dev <[hidden email]>
Date:        12/09/2016 13:31
Subject:        Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        [hidden email]





@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From:        John Ament <[hidden email]>
> >To:        cdi-dev <[hidden email]>
> >Date:        11/09/2016 20:04
> >Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by:        [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> >
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
> >[hidden email]
> >
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
> [hidden email]
>
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
[hidden email]
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

_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

John Ament

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 <[hidden email]>
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        John Ament <[hidden email]>
To:        Matej Novotny <[hidden email]>, Mark Struberg <[hidden email]>
Cc:        Emily Jiang/UK/IBM@IBMGB, cdi-dev <[hidden email]>
Date:        12/09/2016 13:31
Subject:        Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        [hidden email]





@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From:        John Ament <[hidden email]>
> >To:        cdi-dev <[hidden email]>
> >Date:        11/09/2016 20:04
> >Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by:        [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> >
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
> >[hidden email]
> >
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
> [hidden email]
>
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Tomas Remes

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

Thanks
Tom

----- Original Message -----
From: "John Ament" <[hidden email]>
To: "Emily Jiang" <[hidden email]>
Cc: "cdi-dev" <[hidden email]>
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 <[hidden email]>
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From: John Ament <[hidden email]>
To: Matej Novotny <[hidden email]>, Mark Struberg <[hidden email]>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <[hidden email]>
Date: 12/09/2016 13:31
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by: [hidden email]




@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From: John Ament <[hidden email]>
> >To: cdi-dev <[hidden email]>
> >Date: 11/09/2016 20:04
> >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by: [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> > 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
> >[hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

John Ament

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 <[hidden email]>
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
github.com
core - Weld, including integrations for Servlet containers and Java SE, examples and documentation



Thanks
Tom

----- Original Message -----
From: "John Ament" <[hidden email]>
To: "Emily Jiang" <[hidden email]>
Cc: "cdi-dev" <[hidden email]>
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 <[hidden email]>
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From: John Ament <[hidden email]>
To: Matej Novotny <[hidden email]>, Mark Struberg <[hidden email]>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <[hidden email]>
Date: 12/09/2016 13:31
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by: [hidden email]




@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From: John Ament <[hidden email]>
> >To: cdi-dev <[hidden email]>
> >Date: 11/09/2016 20:04
> >Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by: [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> > 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
> >[hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
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.
_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Should javax.enterprise.inject.Produces be inherited?

Emily Jiang
In reply to this post by John Ament
John,

Basically what you suggested is to omit the @Produces on overriding the producer methods.

I am trying to spell out the gap: I am not sure whether the user scenario, where you would override the method but not adding @Produces, is useful. Is this potentially used by any testing apps? If you don't add @Produces on overriding a producer method, when the container calls the producer method, which one will be invoked?

Something related to this area, for the following two code snippets, the first producer is a kind of alternative even though not annotating with @Alternative. They are the same, right?

@Alternative
@Priority(100)
@ApplicationScoped
public class BoopAlternative extends Boop{
   @Override
   @Produces
   public Simpler makeSimpler() {
       return new Simpler("Boop2");
   }

@Alternative
@Priority(100)
@ApplicationScoped
public class BoopAlternative extends Boop{
   @Override
   @Produces

    @Alternative
   public Simpler makeSimpler() {
       return new Simpler("Boop2");
   }



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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        John Ament <[hidden email]>
To:        Emily Jiang/UK/IBM@IBMGB
Cc:        cdi-dev <[hidden email]>
Date:        13/09/2016 11:38
Subject:        Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        [hidden email]





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 <[hidden email]>
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: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB





From:        
John Ament <[hidden email]>
To:        
Matej Novotny <[hidden email]>, Mark Struberg <[hidden email]>
Cc:        
Emily Jiang/UK/IBM@IBMGB, cdi-dev <[hidden email]>
Date:        
12/09/2016 13:31
Subject:        
Re: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by:        
[hidden email]





@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 <[hidden email]>
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" <[hidden email]>
> To: "John Ament" <[hidden email]>, "Emily Jiang" <[hidden email]>
> Cc: "cdi-dev" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> >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: [hidden email]
> >Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> >
> >
> >
> >From:        John Ament <[hidden email]>
> >To:        cdi-dev <[hidden email]>
> >Date:        11/09/2016 20:04
> >Subject:        [cdi-dev] Should javax.enterprise.inject.Produces be
> >inherited?
> >Sent by:        [hidden email]
> >>________________________________
> >
> >
> >
> >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
> >[hidden email]
> >
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
> >[hidden email]
> >
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
> [hidden email]
>
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
[hidden email]

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
[hidden email]
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

_______________________________________________
cdi-dev mailing list
[hidden email]
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.