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

Jozef Hartinger (JIRA) jira-events at lists.jboss.org
Thu Oct 18 02:48:02 EDT 2012


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

Jozef Hartinger edited comment on CDI-129 at 10/18/12 2:46 AM:
---------------------------------------------------------------

{quote} The key point here is what get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd. {quote}

Unfortunatelly I cannot see the code anywhere so this might not be entirely accurate but I'd like to point out that this problem is orthogonal to scoping of the application scope. The same thing would happen for a @Dependent scoped bean or a @Request scoped bean. Although Mark thinks that restricting @ApplicationScoped per war fixes this it actually does not.

{quote} Jozefs way is technically valid, but a no-go from a user perspective imo as it would lead to having different contextual instances for the same injection points across your application.{quote}

I disagree. If you want to override a certain bean globally, put the alternative into a shared jar or into another jar that is visible to all the web applications. If you only want to change the behavior in one of the web applications, put the alternative bean into the web application. I find this way consistent (because it does not create exceptions to rules), straightforward and powerful (because you can choose out of multiple options without introducing new scopes).
                
      was (Author: jharting):
    > The key point here is what get's injected into MailService, which is an EAR bean, is different depending on which WAR you are in, which is a little odd.

Unfortunatelly I cannot see the code anywhere so this might not be accurate but I'd like to point out that this problem is orthogonal to scoping of the application scope. The same thing would happen for a @Dependent scoped bean or a @Request scoped bean. Although Mark thinks that restricting @ApplicationScoped per war fixes this it actually does not.

> Jozefs way is technically valid, but a no-go from a user perspective imo as it would lead to having different contextual instances for the same injection points across your application.

I disagree. If you want to override a certain bean globally, put the alternative into a shared jar or into another jar that is visible to all the web applications. If you only want to change the behavior in one of the web applications, put the alternative bean into the web application. I find this way consistent (because it does not create exceptions to rules), straightforward and powerful (because you can choose out of multiple options without introducing new scopes).
                  
> 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


More information about the cdi-dev mailing list