Re: [cdi-dev] [weld-dev] Question about the spec for BeanManager.getBeans
by Emily Jiang
Matej,
Thanks for your quick reply!
I think the spec is quite clear by saying the candidates of typesafe
resolutions defined in Performing typesafe resolutions... surely a
disabled bean cannot be a candidate. it is simply disquailified.
It did not say eliminate all beans but one though. I think it should be
eliminate disqualified ones and leave all qualified at least.
I am sending to cdi-dev for clarification. Antoine, please comment.
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, Liberty Architect for MicroProfile and CDI
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: Matej Novotny <manovotn(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Emily Jiang <EMIJIANG(a)uk.ibm.com>
Date: 24/08/2018 16:17
Subject: Re: [weld-dev] Question about the spec for
BeanManager.getBeans
Hi
Looking at spec 11.3.6. Obtaining a Bean by type[1] I can see that the
paragraph ends with "according to the rules for candidates of typesafe
resolution defined in Performing typesafe resolution.".
The important word here is *candidates* IMO.
The way typesafe resolution is defined, both the original bean and the
alternatives are candidates. According to spec, the original bean is still
considered enabled[2]
Note that CDI spec doesn't say that @Alternative would completely
eliminate the original bean, it just takes precedence during resolution
(as opposed to what specialization does[3]).
Last but not least, one thought - if the getBeans() method was to perform
a typesafe resolution and eliminate all but one bean - why would it return
a Set (and not throw unsatisfied/ambiguous exceptions)? :)
Matej
______________________________________________________________________________
[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bm_obtain_bean_by_type
[2]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement
[3]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization
----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Emily Jiang" <EMIJIANG(a)uk.ibm.com>
> Sent: Friday, August 24, 2018 3:10:05 PM
> Subject: [weld-dev] Question about the spec for BeanManager.getBeans
>
> Hello
>
> I was made aware of the difference on the return of
> beanManager.getBeans(Object.class) between OWB and Weld
>
> In OWB, it returns all beans, unless there is an enabled @alternative
within
> the application. If there is an enabled @alternative getBeans() only
returns
> beans annotated @alternative.
>
> However, in Weld, it returns all beans even with an enabled
@alternative.
>
> The JavaDoc for BeanMnanager says "according to the rules of typesafe
> resolution" and in the CDI 1.0 spec under typesafe resolution I find one
> mention of alternatives: “When an ambiguous dependency exists, the
container
> attempts to resolve the ambiguity. The container eliminates all eligible
> beans that are not alternatives, except for producer methods and fields
of
> beans that are alternatives.” (This text is also in the CDI 1.2 spec)
>
> However this would imply that if there are no enabled @Alternatives an
> ambiguous resolution like beanManager.getBeans(Object.class) should
discard
> everything. In this case, the Weld behaviour is incorrect.
> beanManager.getBeans() should only return the resolved or enabled beans.
>
> Regards
> Benjamin
>
> Can someone verify this?
> 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
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/weld-dev
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
5 years, 8 months
[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-591 at 8/24/18 4:49 AM:
------------------------------------------------------------
Up!
We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217
So why not finally make it an official part of the API?
Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.Annotated'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod or AnnotatedConstructor. Often you need other Annotations than just the InterceptorBinding.
was (Author: struberg):
Up!
We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217
So why not finally make it an official part of the API?
Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.AnnotatedMethod'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod. Often you need other Annotations than just the InterceptorBinding.
> Easy way to get an interceptor model
> ------------------------------------
>
> Key: CDI-591
> URL: https://issues.jboss.org/browse/CDI-591
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-591:
-----------------------------------
Up!
We had the following report from Arjan and he pointed out that Weld since introduced a non-portable way to do exactly that.
https://issues.apache.org/jira/browse/OWB-1217
So why not finally make it an official part of the API?
Could think about extending the InvocationContext. Not sure how we could do this as part of the Interceptors spec as it doesn't know about AnnotatedTypes at all. We could either subclass it to a CdiInvocationContext. Or define a standard parameter in the Map. E.g. 'jcdi.intercepted.AnnotatedMethod'. It should not only contain the InterceptorBindings but the whole AnnotatedMethod. Often you need other Annotations than just the InterceptorBinding.
> Easy way to get an interceptor model
> ------------------------------------
>
> Key: CDI-591
> URL: https://issues.jboss.org/browse/CDI-591
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-733) javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-733?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-733:
----------------------------------------
There is an alternative: make the Type of TypeVariable provided in the constructor instead of extracting it. This would break the type safety in TypeVariable construction (but when intended) but nowhere else.
> javax.enterprise.event.Event#select shouldnt use TypeLiteral but Type
> ---------------------------------------------------------------------
>
> Key: CDI-733
> URL: https://issues.jboss.org/browse/CDI-733
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
> Priority: Minor
>
> Goal is to enable a bit more meta programming and in particular instantiation of custom parameterized type of events, currently it requires to go through the bean manager whereas the event would be a natural place to resolve an event.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-627:
-----------------------------------
I see no reason to move this discussion anywhere - this ticket is solved and deals with CDI 2.0.
Not that there was any _discussion_ anyway, last comment was 17th Nov 2016 until recently.
bq. The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
That's a bold statement; I wonder if it is the only such change we would find there.
Anyhow, it is a bit late to discuss what should or should not have been in CDI 1.2 as that is no longer developed.
Now we just have to move onwards and drag the legacy behind us :-)
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-627 at 8/17/18 4:15 AM:
------------------------------------------------------------
This bug actually blow up in our face in many projects!
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.
We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!
So I see absolutely no reason why Weld refuses to fix this broken behaviour!
*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.
*Edit2*: can we probably move all this discussion to a Weld2 ticket? The CDI spec part is imo fine now.
was (Author: struberg):
This bug actually blow up in our face in many projects!
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.
We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!
So I see absolutely no reason why Weld refuses to fix this broken behaviour!
*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-627 at 8/17/18 4:00 AM:
------------------------------------------------------------
This bug actually blow up in our face in many projects!
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.
We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!
So I see absolutely no reason why Weld refuses to fix this broken behaviour!
*Edit*: It works perfectly fine in ALL Weld-1 and Weld-3 versions. And as far as I remember it even worked perfectly fine in earlier Weld-2 versions. It just got broken in younger Weld2 versions.
was (Author: struberg):
This bug actually blow up in our face in many projects!
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.
We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!
So I see absolutely no reason why Weld refuses to fix this broken behaviour!
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-627:
-----------------------------------
This bug actually blow up in our face in many projects!
The section in the CDI-1.2 spec is a backward incompatible wording and thus void per the JCP rules.
Of course it was not introduced intentional. We tinkered with the wording in 1.2 because from the original wording it was not obvious that Alternatives added via Extensions are also affected by beans.xml. And by doing that we kind of mangled the wording which covered classic @Alternative MangedBeans. So this was nothing which was intended but purely bad luck.
We fixed it by 'repairing' the wording in CDI-2.0. This wording was intended to CHANGE NOTHING! It was really just a wording clarification. It was definitely no new feature! From our *intention* CDI-1.0, 1.1, 1.2, 2.0 should behave *exactly* the same in regard to alternatives enabled via beans.xml. The difference in behaviour was NOT intended but really just messed up wording!
So I see absolutely no reason why Weld refuses to fix this broken behaviour!
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 8 months
