[cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

[Jozef Hartinger (JIRA)]

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

Jozef Hartinger edited comment on CDI-129 at 10/18/12 8:49 AM:
---------------------------------------------------------------

{quote}Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war.

We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.{quote}

That is a pretty biased summary that ignores quite a few parts of the discussion above. I'll try to come up with a more objective one:

After discussion with Mark and Stuart we all can see that there are two orthogonal issues involved:
* wiring 
** CDI is based on static wiring where the Bean for an injection point is resolved based on the module the class that declares the injection point is packaged in. (as explained in Section 5.1 of the CDI 1.0 spec)
** Mark thinks that a semi-static approach, where the Bean for an injection point is resolved based on the context of the thread in which the execution occurs is more appropriate. That means that if MailService is invoked from a web application that packages class B (which specializes A), MailService will also operate on the specialized version (B).
* the actual span of the @ApplicationScoped (either per-war or per entire ear)
                
      was (Author: jharting):
    {quote}Jozef, thanks for your input so far. There are some valid points in your argumentation and we need to clarify those. I guess we now have a pretty clear picture that EAR scenario is broken in CDI 1.0 if we use scopes broader than 1 contextual instance per war.

We also outlined 3 different approaches to treat such scopes. We will schedule an EG meeting to discuss this in the EG.{quote}

That is a pretty biased conclusion that ignores quite a few parts of the discussion above. I'll try to come up with a more objective one:

After discussion with Mark and Stuart we all can see that there are two orthogonal issues involved:
* wiring 
** CDI is based on static wiring where the Bean for an injection point is resolved based on the module the class that declares the injection point is packaged in. (as explained in Section 5.1 of the CDI 1.0 spec)
** Mark thinks that a semi-static approach, where the Bean for an injection point is resolved based on the context of the thread in which the execution occurs is more appropriate. That means that if MailService is invoked from a web application that packages class B (which specializes A), MailService will also operate on the specialized version (B).
* the actual span of the @ApplicationScoped (either per-war or per entire ear)
                  
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
>                 Key: CDI-129
>                 URL: https://issues.jboss.org/browse/CDI-129
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.0
>            Reporter: Mark Struberg
>            Assignee: Pete Muir
>             Fix For: 1.1 (Proposed)
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira