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@uk.ibm.com

> Lotus Notes: Emily Jiang/UK/IBM@IBMGB

> 

> 

> 

> 

> From: Matej Novotny <manovotn@redhat.com>

> To: Benjamin Confino <BENJAMIC@uk.ibm.com>

> Cc: weld-dev@lists.jboss.org, Emily Jiang <EMIJIANG@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@uk.ibm.com>

>  > To: weld-dev@lists.jboss.org

>  > Cc: "Emily Jiang" <EMIJIANG@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@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@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