[
https://issues.jboss.org/browse/CDI-245?page=com.atlassian.jira.plugin.sy...
]
Mark Struberg edited comment on CDI-245 at 8/16/12 8:49 AM:
------------------------------------------------------------
Today, the only thing you can inject in a portable fashion is the
BeanManager.
In CDI-1.0 it's just undefined what you can inject at bootup. We
can only exclude what explicitely is forbidden or defined to get started afterwards. But
there is currently no wording that specifies that e.g. @Stateless beans cannot be
@Injected.
For Extensions I looked at 11.5:
{quote}
The container instantiates a single instance of each extension at the beginning of the
application initialization process and maintains a reference to it until the application
shuts down. The container delivers event notifications to this instance by calling its
observer methods.
For each service provider, the container must provide a bean of scope @ApplicationScoped
and qualifier @Default, sup- porting injection of a reference to the service provider
instance. The bean types of this bean include the class of the service provider and all
superclasses and interfaces.
{quote}
Thus
a.) all Extensions get loaded before the first container lifecycle event gets fired
b.) all Extensions are beans which are available for injection
c.) all Extensions are @ApplicationScoped.
I guess the problem is that the ApplicationContext only gets started after
AfterDeploymentValidation, right?
In DeltaSpike we currently use the Extension injection for runtime communication between
an Interceptor and it's Extension and not at boot time.
was (Author: struberg):
Today, the only thing you can inject in a portable fashion is the
BeanManager.
In CDI-1.0 it's just undefined what you can inject at bootup. We
can only exclude what explicitely is forbidden or defined to get started afterwards. But
there is currently no wording that specifies that e.g. @Stateless beans could be
@Injected.
For Extensions I looked at 11.5:
{quote}
The container instantiates a single instance of each extension at the beginning of the
application initialization process and maintains a reference to it until the application
shuts down. The container delivers event notifications to this instance by calling its
observer methods.
For each service provider, the container must provide a bean of scope @ApplicationScoped
and qualifier @Default, sup- porting injection of a reference to the service provider
instance. The bean types of this bean include the class of the service provider and all
superclasses and interfaces.
{quote}
Thus
a.) all Extensions get loaded before the first container lifecycle event gets fired
b.) all Extensions are beans which are available for injection
c.) all Extensions are @ApplicationScoped.
I guess the problem is that the ApplicationContext only gets started after
AfterDeploymentValidation, right?
In DeltaSpike we currently use the Extension injection for runtime communication between
an Interceptor and it's Extension and not at boot time.
Promote the right way how extensions should communicate with each
other during container initialization
-------------------------------------------------------------------------------------------------------
Key: CDI-245
URL:
https://issues.jboss.org/browse/CDI-245
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.0, 1.1.EDR1
Reporter: Martin Kouba
Fix For: 1.1 (Proposed)
This is not clear right now. The spec allows (does not forbid) extensions to fire regular
events via {{BeanManager}} and I believe this should be _the right way_. See also CDI-109
discussion. However we should also state that extensions _may not fire container lifecycle
events_ as this could lead to unexpected results (and it's pretty broken imho).
--
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