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&pag...,
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&pag...
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) <jira(a)apache.org>
À : deltaspike-dev(a)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.j...
]
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