[
https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-712:
----------------------------------
bq. A Long Bean would also work but then it would go through the whole CDI stack for EACH
and every invocation!
Not a big deal.
bq. Also the spec does NOT state that one cannot provide an Alternative for built-in
beans.
Agreed.
bq. Note that it is also important to allow custom implementations of
javax.inject.Provider as the Container would otherwise not be able to implement JSR-330
afaict.
I don't understand even a little.
bq. This is just a standard bean...
It's not standard in the way that it must satisfy all {{Instance<X>}} or
{{Provider<X>}} for any legal bean type {{X}} and qualifiers are also handled
specially. In other words, the built-in bean must be treated in a special way.
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)