[
https://issues.apache.org/jira/browse/DELTASPIKE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697191#comment-13697191
]
Gerhard Petracek commented on DELTASPIKE-335:
---------------------------------------------
nobody continued with it so far. the real issue is that there is no portable
behaviour (for EARs) across the servers we support. a workaround for one fails
on others. as far as i've seen we need a mechanism to support different modes.
esp. the cases with tmp-classloaders (and/or -bean-managers) are hard to solve.
> 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
> Reporter: Gerhard Petracek
> Assignee: Mark Struberg
> Fix For: 0.5
>
>
> #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
