[
https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-712:
-----------------------------------
Hi [~mkouba] Thanks for the catch with the 'hidden' instance. That is fixed now in
the OpenWebBeans trunk.
I see that so far most containers do not properly implement this feature, so I agree we
should not yet advertise this feature ;)
Otoh I think it is perfectly covered by the spec and we should support it in our
implementations. We allow a lot of things with the built-in Instance Bean. We even allow
to decorate them (it's even in the TCK). So why should it be disallowed to provide an
Alternative for Provider<X>?
Clarify whether is should be possible to "override"
built-in Instance/Provider
------------------------------------------------------------------------------
Key: CDI-712
URL:
https://issues.jboss.org/browse/CDI-712
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Martin Kouba
In theory, an extension could register an alternative custom bean to override the
built-in Instance/Provider bean for injection points such as {{@Inject
Provider<String>}}.
It is not forbidden at the moment. The spec only states that there must be a built-in
bean eligible for any injection point with Instance/Provider required type and any
qualifier. See also
https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance.
It seems to be a powerful feature. On the other hand, it might be a source of confusion.
Take for example this injection point:
{code:java}
@Inject
@MyQualifier
Instance<String> instance;
{code}
The qualifier is now considered when calling {{instance.get()}} and NOT when resolving
the injection point.
Note that the spec already allows to decorate built-in beans.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)