[cdi-dev] [JBoss JIRA] (CDI-245) Promote the right way how extensions should communicate with each other during container initialization

[Mark Struberg (JIRA)]

    [ https://issues.jboss.org/browse/CDI-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711989#comment-12711989 ] 

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