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

Dupont Dupont (JIRA) jira-events at lists.jboss.org
Thu Mar 28 15:08:42 EDT 2013


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

Dupont Dupont commented on CDI-129:
-----------------------------------

I have quite a few questions / remarks about it (some of which are already mentioned in CDI-129, but don't have definite answers).

# both @ApplicationScoped and @ModuleScoped visibility are needed (see [DELTASPIKE-335|https://issues.apache.org/jira/browse/DELTASPIKE-215])
  Unlike https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602519&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12602519, I don't think we should automatically share @ApplicationScoped depending on whether the bean archive is packaged in EAR or in WAR (i.e. some cdi extension could use @ModuleScoped for JSF phase listeners and @ApplicationScoped for another purpose, so automatically sharing @ApplicationScoped would result in an artificial jar split for such extensions and packaging difficulties for the end-user).
# What happens if a @ApplicationScoped bean is packaged in WEB-INF/lib for EAR applications ?
  IMO it should result in an exception, otherwise for EAR containing multiple WARs it will lead to inconsistencies.
# What happens if a @ApplicationScoped bean is packaged in WEB-INF/lib for WAR application (no EAR) ?
  IMO it should be fine otherwise, we won't be able to use CDI in tomcat or with simple wars on JBoss otherwise.
# What happens for EAR with multiple WARs if a CDI bean with same name is packaged in WEB-INF/lib of each wars ?
  With JBoss 7.1.x this leads to DeploymentException: WELD-001414 Bean name is ambiguous.
  This means that CDI bean archives must absolutely be packaged at the EAR level on JBoss 7.1.x (and for JSF webapp, JSF libs must be packaged in WEB-INF/lib in order for JSF to scan faces-config.xml - this leads to some difficulties if I package JSF artifacts and CDI beans in the same archive).
  This leads to the question : can CDI bean archives be packaged in WEB-INF/lib and still be portable (not in Java EE 6) ?
  IMO, it shouldn't result in an exception.
# Same question if the a bean of the same class is packaged in WEB-INF/lib ?
  IMO, it shouldn't result in an exception.
# What happens if a @ApplicationScoped bean of an EAR is Specialized or has an Alternative in a WEB-INF/lib ?
  Discussed previously : https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602718&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12602718
  IMO, CDI impl should raise an exception (if we agree for 2. that @ApplicationScoped beans can only be defined at the EAR level for an 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
>              Labels: application-scoped, visibility
>             Fix For: TBD
>
>
> 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