3:02 p.m.
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.
5:59 p.m.
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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: cdi-dev <cdi-dev(a)lists.jboss.org>
Date: 11/09/2016 20:04
Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
inherited?
Sent by: cdi-dev-bounces(a)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(a)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
6:56 p.m.
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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: cdi-dev <cdi-dev(a)lists.jboss.org>
Date: 11/09/2016 20:04
Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by: cdi-dev-bounces(a)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(a)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 Info Page - JBoss
Developer<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.
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.
2 a.m.
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(a)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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: cdi-dev <cdi-dev(a)lists.jboss.org>
Date: 11/09/2016 20:04
Subject: [cdi-dev] Should javax.enterprise.inject.Produces be inherited?
Sent by: cdi-dev-bounces(a)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(a)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 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(a)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.
3:28 a.m.
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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)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 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(a)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(a)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.
8:28 a.m.
@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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss
Developer<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
>cdi-dev(a)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(a)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.
4:37 a.m.
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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Matej Novotny <manovotn(a)redhat.com>, Mark Struberg
<struberg(a)yahoo.de>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <cdi-dev(a)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(a)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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)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(a)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(a)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(a)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
6:33 a.m.
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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Matej Novotny <manovotn(a)redhat.com>, Mark Struberg
<struberg(a)yahoo.de>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <cdi-dev(a)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(a)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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/cdi-dev
cdi-dev Info Page - JBoss
Developer<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
>cdi-dev(a)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(a)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(a)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.
8:51 a.m.
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" <john.ament(a)spartasystems.com>
To: "Emily Jiang" <EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Matej Novotny <manovotn(a)redhat.com>, Mark Struberg <struberg(a)yahoo.de>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <cdi-dev(a)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(a)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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)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(a)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(a)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(a)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(a)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
9:15 a.m.
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(a)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:/...
Test scope of alternative producer is not inherited. ·
weld/core@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(a)spartasystems.com>
To: "Emily Jiang" <EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Matej Novotny <manovotn(a)redhat.com>, Mark Struberg <struberg(a)yahoo.de>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <cdi-dev(a)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(a)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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)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(a)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(a)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(a)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(a)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.
9:34 a.m.
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: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Emily Jiang/UK/IBM@IBMGB
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Date: 13/09/2016 11:38
Subject: Re: [cdi-dev] Should javax.enterprise.inject.Produces be
inherited?
Sent by: cdi-dev-bounces(a)lists.jboss.org
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(a)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(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
From: John Ament <john.ament(a)spartasystems.com>
To: Matej Novotny <manovotn(a)redhat.com>, Mark Struberg
<struberg(a)yahoo.de>
Cc: Emily Jiang/UK/IBM@IBMGB, cdi-dev <cdi-dev(a)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(a)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(a)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(a)yahoo.de>
To: "John Ament" <john.ament(a)spartasystems.com>, "Emily Jiang"
<EMIJIANG(a)uk.ibm.com>
Cc: "cdi-dev" <cdi-dev(a)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(a)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(a)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(a)uk.ibm.com
>Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
>From: John Ament <john.ament(a)spartasystems.com>
>To: cdi-dev <cdi-dev(a)lists.jboss.org>
>Date: 11/09/2016 20:04
>Subject: [cdi-dev] Should javax.enterprise.inject.Produces be
>inherited?
>Sent by: cdi-dev-bounces(a)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(a)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(a)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(a)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(a)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(a)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
2786
days inactive
2788
days old
10 comments
5 participants
participants (5)
-
Emily Jiang -
John Ament -
Mark Struberg -
Matej Novotny -
Tomas Remes