[cdi-dev] [JBoss JIRA] (CDI-231) Clarify if Alternatives are filtered in BeanManager#getBeans() or #resolve()
[
https://issues.jboss.org/browse/CDI-231?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-231:
-----------------------------------
It's only clear if you omit the most important part ;) Please add the following to
your quote above:
{quote}
...according to the rules of typesafe resolution defined in Section 5.2, “Typesafe
resolution”.
{quote}
But according to the rules of scientific citing, referencing 5.2 includes all its sub
bullets, thus also 5.2.1 (resolving Alternatives).
If that would not include 5.2.1 then also oher important sub-bullets would be missing e.g.
it would also leave out the reference to 'primitives and nullable types'
Clarify if Alternatives are filtered in BeanManager#getBeans() or
#resolve()
----------------------------------------------------------------------------
Key: CDI-231
URL: https://issues.jboss.org/browse/CDI-231
Project: CDI Specification Issues
Issue Type: Clarification
Components: Resolution
Affects Versions: 1.0, 1.1.EDR1
Reporter: Mark Struberg
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
The spec and javadoc are not really clear if the @Alternative filter defined in
"5.2.1. Unsatisfied and ambiguous dependencies" is already performed in
BeanManager#getBeans() or only later in BeanManager#resolve().
Back in 2009 I did a blind test with an old Weld version which only returned
@Alternatives in getBeans() and all other beans got filtered out. This seems to have
changed now (since quite some time).
Can we make this more clear what should happen in getBeans() and what should happen in
resolve()?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira