[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs
by Dupont Dupont (JIRA)
[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ]
Dupont Dupont commented on CDI-129:
-----------------------------------
I have quite a few questions / remarks about it (some of which are already mentioned in CDI-129, but don't have definite answers).
# both @ApplicationScoped and @ModuleScoped visibility are needed (see [DELTASPIKE-335|https://issues.apache.org/jira/browse/DELTASPIKE-215])
Unlike https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602519&page=co..., 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).
# 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.
# 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.
# 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.
# Same question if the a bean of the same class is packaged in WEB-INF/lib ?
IMO, it shouldn't result in an exception.
# What happens if a @ApplicationScoped bean of an EAR is Specialized or has an Alternative in a WEB-INF/lib ?
Discussed previously : https://issues.jboss.org/browse/CDI-129?focusedCommentId=12602718&page=co...
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).
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
> Key: CDI-129
> URL: https://issues.jboss.org/browse/CDI-129
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Labels: application-scoped, visibility
> Fix For: TBD
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes.
--
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
11 years, 9 months
CDI-129 and DELTASPIKE-335
by Adrian Gonzalez
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=co...,
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=co...
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
11 years, 9 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Pete Muir edited comment on CDI-361 at 3/28/13 2:56 PM:
--------------------------------------------------------
https://github.com/jboss/cdi/pull/189
was (Author: pmuir):
https://github.com/jboss/cdi/pull/189 -- here is the pull, currently only covers part 1
> Issues with passivation capable beans and dependencies
> ------------------------------------------------------
>
> Key: CDI-361
> URL: https://issues.jboss.org/browse/CDI-361
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> h3. Dependencies of interceptors and decorators:
> {quote}
> If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean:
> * is not passivation capable,
> * has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, or
> * has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not
> a dependent scoped bean and that is not a passivation capable dependency, or
> * has an interceptor or decorator with a non-transient injected field that does not resolve to a passivation capable dependency,
> then the container automatically detects the problem and treats it as a deployment problem.
> {quote}
> It is not enough to validate injected fields of interceptors/decorators only. The specification should require validation of *all* injection points of an interceptor / decorator also considering @TransientReference
> h3. Decorators of built-in beans should be passivation capable
> {quote}If a managed bean or a stateful session bean which declares a passivating scope type, has a decorator or interceptor which is not
> a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem.{quote}
> Combined with the quote above the specification only requires injection points of a decorator of a built-in bean to be passivation capable dependencies. The specification should also require the decorators themselves to be passivation capable dependencies.
--
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
11 years, 9 months
[JBoss JIRA] (CDI-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-360:
-------------------------------
Ok, I will fix this by adding validation that custom beans which have a passivating scope are passivation capable.
> NormalScoped Bean<T> should all be forced to implement PassivationCapable
> -------------------------------------------------------------------------
>
> Key: CDI-360
> URL: https://issues.jboss.org/browse/CDI-360
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> When serializing a Contextual Reference of a CDI bean, we need to transport over it's proxy. This proxy internally need to serialize it's Bean<T>. But this is only really possible if the Bean implements PassivationCapable. Any attempt to use the type + qualifier is doomed to fail, as this still leaves room for clashes. E.g. if an Extension registers multiple Bean<T> with Object.class and @Default qualifier but a different name (kind of Spring XML style).
> 6.6.2 comes most close to this requirement, though it doesn't really define that all NormalScoped beans really need to implement PassivationCapable. At least it seems to point into the right direction - but it's nowhere near a clear definition.
> We should force Containers to check whether Bean<T> which serve a NormalScoped scope do implement PassivationCapable.
--
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
11 years, 9 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-361:
-------------------------------
https://github.com/jboss/cdi/pull/189 -- here is the pull, currently only covers part 1
> Issues with passivation capable beans and dependencies
> ------------------------------------------------------
>
> Key: CDI-361
> URL: https://issues.jboss.org/browse/CDI-361
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> h3. Dependencies of interceptors and decorators:
> {quote}
> If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean:
> * is not passivation capable,
> * has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, or
> * has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not
> a dependent scoped bean and that is not a passivation capable dependency, or
> * has an interceptor or decorator with a non-transient injected field that does not resolve to a passivation capable dependency,
> then the container automatically detects the problem and treats it as a deployment problem.
> {quote}
> It is not enough to validate injected fields of interceptors/decorators only. The specification should require validation of *all* injection points of an interceptor / decorator also considering @TransientReference
> h3. Decorators of built-in beans should be passivation capable
> {quote}If a managed bean or a stateful session bean which declares a passivating scope type, has a decorator or interceptor which is not
> a passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem.{quote}
> Combined with the quote above the specification only requires injection points of a decorator of a built-in bean to be passivation capable dependencies. The specification should also require the decorators themselves to be passivation capable dependencies.
--
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
11 years, 9 months
[JBoss JIRA] (CDI-316) Adopt usage of the @since Javadoc tag
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-316?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-316.
---------------------------
Assignee: Pete Muir
Resolution: Done
I did this, but forgot to close it.
> Adopt usage of the @since Javadoc tag
> -------------------------------------
>
> Key: CDI-316
> URL: https://issues.jboss.org/browse/CDI-316
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Javadoc and API
> Affects Versions: 1.1.PRD
> Reporter: George Gastaldi
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> It's a good practice to use the @since javadoc tag in the methods and interfaces/classes created in this new version.
> This is necessary when one need to figure out if some feature is targeted to work in 1.1 only, for example.
> This issue was created so that all the API code can be reviewed before the next release. Some classes already have this information, other still don't (@Vetoed is one that is missing, afaik)
--
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
11 years, 9 months
[JBoss JIRA] (CDI-351) Implicit bean archive compatibility issue
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-351?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-351:
-------------------------------
Bill Shannon suggests setting bean discovery mode to none in bean archives with extensions automatically.
> Implicit bean archive compatibility issue
> -----------------------------------------
>
> Key: CDI-351
> URL: https://issues.jboss.org/browse/CDI-351
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> Assume an existing extension library (CDI 1.0). This library is not deployed as a bean archive (it does not contain beans.xml). Instead, the library contains an extension which registers beans, interceptors, etc. using BeforeBeanDiscovery.addAnnotatedType().
> With CDI 1.1 the no-bean-archive assumption no longer holds and since a scope annotation is used somewhere in the extension, this extension is now recognized as an implicit bean archive. That causes the discovered beans to clash with those added programatically.
> *Note that it is not possible to fix this by adding beans.xml with bean-discovery-mode set to "none". This would fix the problem in CDI 1.1 but the presence of beans.xml would break the extension in a CDI 1.0 container*.
--
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
11 years, 9 months
[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-334.
---------------------------
Resolution: Done
Changes merged
> Issues with global enablement of alternatives
> ---------------------------------------------
>
> Key: CDI-334
> URL: https://issues.jboss.org/browse/CDI-334
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Resolution
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> * Section 5.1 last paragraph does not reflect global enablement of alternatives.
> * Section 5.1.1 fails to define how @Priority relates to:
> ** alternative stereotypes
> ** producers
> * Section 5.1.6 does not reflect global enablement of alternatives
> Section 5.2.2:
> ** generally the section needs to take global enablement of alternatives into account
> ** "If all the beans left are alternatives with a priority, then the container will select the alternative with the highest priority, and the
> ambiguous dependency is called resolvable."
> *** there is no guarantee that there is a single alternative with the highest priority. The spec should define what happens in that case.
> *** also, the statement should not only consider "alternatives" but also producers defined on alternatives
> * Section 5.3.1 - same as 5.2.2
> * Recommended priority ranges for alternatives should be defined somewhere
--
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
11 years, 9 months
[JBoss JIRA] (CDI-352) Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-352?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-352.
---------------------------
Resolution: Done
I've tried to make it clearer that this is wrong. Is there a CDI TCK issue for this?
> Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive
> ------------------------------------------------------------------------------------------------------
>
> Key: CDI-352
> URL: https://issues.jboss.org/browse/CDI-352
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> There is a TCK test in which an archive with the beans.xml file enables an interceptor (by listing the interceptor class name in beans.xml). The interceptor class is packaged in another library archive which is not a bean archive. It is not clear from the specification if an interceptor bound using interceptor bindings may only be packaged in a bean archive or whether a CDI implementation should pull the interceptor definition based on the declaration in the beans.xml file even if the interceptor is outside of a bean archive.
--
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
11 years, 9 months