Hello, Sorry to add more comments on this issue.
I have quite a few questions / remarks about it (some of which are already mentioned in CDI-129, but don't have definite answers). 1. @ApplicationScoped and @ModuleScoped visibility are needed (see DELTASPIKE-335) 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). 2. 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. 3. 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. 4. 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. 5. Same question if the a bean of the same class is packaged in WEB-INF/lib ? IMO, it shouldn't result in an exception. 6. What happens if a @ApplicationScoped bean of an EAR is Specialized or has an Alternative in a WEB-INF/lib ? Discussed here : 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). Sorry for the long mail, and hope I don't confuse the issue. Best regards, Adrian P.S posted to both cdi-dev and deltaspike-dev, don't know if this is ok ;( ----- Mail transféré ----- De : Gerhard Petracek (JIRA) <j...@apache.org> À : deltaspike-dev@incubator.apache.org Cc : Envoyé le : Mercredi 27 mars 2013 16h33 Objet : [jira] [Commented] (DELTASPIKE-335) re-visit support of EARs [ https://issues.apache.org/jira/browse/DELTASPIKE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615389#comment-13615389 ] Gerhard Petracek commented on DELTASPIKE-335: --------------------------------------------- for #1 that would mean: we need a concept to detect where (which web-app) a class (config class, phase-listener annotated with @JsfPhaseListener, ...) comes from. -> that's also needed later on for consuming information (which is only related to one web-app). for #2 that would mean: we need @WebApplicationScoped > re-visit support of EARs > ------------------------ > > Key: DELTASPIKE-335 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-335 > Project: DeltaSpike > Issue Type: Task > Affects Versions: 0.4-incubating > Reporter: Gerhard Petracek > Fix For: 0.5-incubating > > > #1 > our current approach to get rid of basic classloader issues (esp. with EARs) > is to collect information during bootstrapping and inject the extension > instance to consume the result later on. that can expose the collected > information of one web-app to other web-apps (of the same EAR). in codi we > used the classloader as key, however, this approach also has disadvantages. > (something like @WebApplicationName would only work in some cases.) > #2 > there was no real agreement about https://issues.jboss.org/browse/CDI-129. > currently we expect that @ApplicationScoped is separated per web-app. > however, that's at least not the case with current versions of weld. > -> (at least for current versions of weld) we have to think about an own > @WebApplicationScoped -- 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
