[
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
