4:08 p.m.
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