Could this be a configurable thing? by default it is EAR wide, but you can configure it with a DS property to be WAR wide ?
2013/3/27 Peter Muir (JIRA) <j...@apache.org>: > > [ > https://issues.apache.org/jira/browse/DELTASPIKE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615168#comment-13615168 > ] > > Peter Muir commented on DELTASPIKE-335: > --------------------------------------- > > Regarding CDI-129, there was a majority in favour of @ApplicationScoped being > EAR wide, however we did not manage to fully address the issue in time, so it > has been deferred to CDI.next. I would expect the resolution to be EAR-wide > then, though, and plan for that in DeltaSpike. > >> 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