[
https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg commented on CDI-712:
-----------------------------------
Not a big deal.
Well, that entirely depends on your performance needs. Do a benchmark. A full bean
resolving is about 10.000 more expensive than a simple get on a cache Map.
In other words, the built-in bean must be treated in a special way.
No, not at all. It must just be *provided* in a special way. That's all.
I mentioned the JSR-330 reference because Provider is not a CDI class at all. It's
from atinject. So the CDI spec must not prevent any other usages.
Also note that built-in beans must be passivation capable
dependencies.
Yes, of course. But I have no clue what this changes regarding to the
current topic?
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)