From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com&gt; To: weld-dev(a)lists.jboss.org Cc: "Emily Jiang" <EMIJIANG(a)uk.ibm.com&gt; 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

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&gt; To: Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; Cc: weld-dev(a)lists.jboss.org, Emily Jiang <EMIJIANG(a)uk.ibm.com&gt; 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&gt; > To: weld-dev(a)lists.jboss.org > Cc: "Emily Jiang" <EMIJIANG(a)uk.ibm.com&gt; > 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 _______________________________________________ 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.