[cdi-dev] [weld-dev] Question about the spec for BeanManager.getBeans

[Martin Kouba]

Hi all,

BeanManager#getBeans() should not apply ambiguous dependency resolution 
rules - see also CDI-231 [1] and related changes. These rules should 
only be applied by BeanManager#resolve().

BeanManager#getBeans() and BeanManager#resolve() are in fact even more 
complicated because they should honor the inter-module injection rules. 
In other words, it also depends where you request the beans from. And 
this is where Weld and OWB differ a lot.

Martin

[1]
https://issues.jboss.org/browse/CDI-231


Dne 24.8.2018 v 23:08 Emily Jiang napsal(a):
> 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 at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> 
> 
> 
> From: Matej Novotny <manovotn at redhat.com>
> To: Benjamin Confino <BENJAMIC at uk.ibm.com>
> Cc: weld-dev at lists.jboss.org, Emily Jiang <EMIJIANG at 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 at uk.ibm.com>
>  > To: weld-dev at lists.jboss.org
>  > Cc: "Emily Jiang" <EMIJIANG at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic