[JBoss JIRA] (CDI-334) Issues with global enablement of alternatives
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-334?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-334:
---------------------------------
5.1.1.1 - it is still unclear how @Priority works with @Alternative producers
5.2.2
{quote}all the beans left are alternatives with a priority, then the container will determine the highest priority value, and eliminate all
beans, *except for producer methods and fields of beans that are alternatives with priorities*, with other priority values. If there
is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.{quote}
So if there is an alternative bean with priority 2000 and a non-alternative producer method defined on an alternative bean with priority 1000 this combination causes an unresolvable ambiguous dependency?
5.3.1 - still outdated
> 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, 1 month
[JBoss JIRA] (CDI-348) Clarify which beans "have" bean defining annotations
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-348?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-348:
-------------------------------------
{quote}The container discovers each Java class with a bean defining annotation in an implicit bean archive.{quote}
The previous change to the specification only defines when a bean is said to have a bean defining annotation. It is still unclear what a "Java class with a bean defining annotation" means.
> Clarify which beans "have" bean defining annotations
> ----------------------------------------------------
>
> Key: CDI-348
> URL: https://issues.jboss.org/browse/CDI-348
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> {quote}Any bean which has scope type is said to have a bean defining annotation.{quote}
> The spec makes this vague statement and provides two examples which only cover the two simplest cases. What remains unclear is:
> - if a bean class inherits a scope annotation definition from a superclass, should it be discovered in an implicit bean archive?
> - if a bean inherits a scope from a stereotype, should it be discovered in an implicit bean archive?
> - if a producer method / field has a scope annotation but the declaring bean is not a bean with bean defining annotation, whould the producer be discovered?
--
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, 1 month
[JBoss JIRA] (CDI-348) Clarify which beans "have" bean defining annotations
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-348?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-348:
---------------------------------
{quote}Any scope type is a bean defining annotation, and any bean which has a scope type declared on the bean class is said to have a bean defining annotation.{quote}
This is quite weirdly specified. Assume the following class:
{noformat}
@ApplicationScoped
public class FooProducer {
@Produces
public Integer produceInteger() {
return 0;
}
}
{noformat}
{quote}bean which has a scope type declared on the bean class is said to have a bean defining annotation{quote}
FooProducer is the bean class of the producer method. However, we cannot say that the producer method *has* a scope type declared on the bean class. It's more of an observation that the bean class of the producer method declares a bean defining annotation.
> Clarify which beans "have" bean defining annotations
> ----------------------------------------------------
>
> Key: CDI-348
> URL: https://issues.jboss.org/browse/CDI-348
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> {quote}Any bean which has scope type is said to have a bean defining annotation.{quote}
> The spec makes this vague statement and provides two examples which only cover the two simplest cases. What remains unclear is:
> - if a bean class inherits a scope annotation definition from a superclass, should it be discovered in an implicit bean archive?
> - if a bean inherits a scope from a stereotype, should it be discovered in an implicit bean archive?
> - if a producer method / field has a scope annotation but the declaring bean is not a bean with bean defining annotation, whould the producer be discovered?
--
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, 1 month
[JBoss JIRA] (CDI-357) @Stateless and @Singleton session beans are no longer passivation capable dependencies
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-357?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-357:
---------------------------------
{quote}all session beans are passivation capable dependencies, {quote}
I don't think *all* session beans can be passivation capable dependencies. Stateless session beans, passivation capable stateful session beans and singletons for sure can but non-passivation capable stateful session beans probably cannot.
> @Stateless and @Singleton session beans are no longer passivation capable dependencies
> --------------------------------------------------------------------------------------
>
> Key: CDI-357
> URL: https://issues.jboss.org/browse/CDI-357
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> This is a regression since 1.0
> CDI 1.0:
> {quote}all session beans are passivation capable dependencies{quote}
> CDI 1.1:
> {quote}all passivation capable beans with scope @Dependent are passivation capable dependencies{quote}
> and
> {quote}As defined by the EJB specification, stateless and singleton session beans are not passivation capable{quote}
--
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, 1 month
[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-319:
---------------------------------
{quote}If packages annotated @Vetoed are split across *jars*, non-portable behavior results.{quote}
*jar* is not entirely accurate. More accurate would be to say "split across *bean archives*"
> Reword part of the @Vetoed section
> ----------------------------------
>
> Key: CDI-319
> URL: https://issues.jboss.org/browse/CDI-319
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> I think the current wording of 3.13 "Vetoing types" is misleading now. E.g. @Vetoed on annotation (qualifier, stereotype) has no effect. Also the spec wording should be synced with @Vetoed javadoc.
> To sum it up: @Vetoed affects classes, interfaces, enums.
> * class -> no container lifecycle event (PAT), no bean or observer methods defined by the class will be installed
> * interface, enum -> no container lifecycle event (PAT)
> I suggest something similar:
> {quote}
> Any Java class, interface, enum or package may be prevented from being considered by CDI by adding the @Vetoed annotation.
> In particular,
> * any beans or observer methods defined by a class annotated with @Vetoed will not be installed
> * no container lifecycle events are fired for classes, interfaces or enums annotated with @Vetoed
> * when @Vetoed placed on package, all classes, interfaces or enums in the package are prevented from being considered by CDI
> {quote}
> The rest is ok.
--
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, 1 month
[JBoss JIRA] (CDI-352) Clarify whether an interceptor/decorator enabled for a bean archive must be packaged in a bean archive
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-352?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-352:
----------------------------------
TCK test removed. See also CDITCK-332
> 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, 1 month
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-274:
-----------------------------------
either that or move the point of the check from currently AfterDeploymentValidation to AfterBeanDiscovery.
This feature got introduced to prevent Extensions from behaving randomly depending on the scan order. If we agree that AfterBeanDiscovery is a save enough point, then I'm also fine with it.
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
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, 1 month
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann commented on CDI-274:
-----------------------------------
I have been running into a similar issue just recently and thought it would be good to share the problem with you guys.
As discussed on the owb user mailing list [1] we use an AfterBeanDiscovery extension that added a bean of a certain type if no bean of this type exists already. We use this extension to add a UserTransaction to the runtime if the runtime does not provide one (inside vs. outside Java EE runtime). My extension used BeanManager#getBeans() for this check.
Because of some owb internal issues I switched from using getBeans to observing ProcessBean to detect the UserTransaction. This works perfectly for my current setup and could be the way to do it with CDI 1.1 where CDI-315 applies.
Nevertheless my solution will only work for "discovered" beans. Am I right that Java EE Resources (such as my UserTransction) are "discovered"? According to ProcessBean javadoc Java EE Resources are treated as producer fields. Right?
Also: Since getBeans shall throw an Exception now would it be worth to add a comment to the spec that an extension can achieve similar results by observing ProcessBean? I got the (now obvious) hint from Arne Limburg...
[1] http://mail-archives.apache.org/mod_mbox/openwebbeans-user/201303.mbox/%3...
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
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, 1 month
[JBoss JIRA] (CDI-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-360:
-----------------------------------
Pete, the real underlying issue is that all the PassivationCapable or not does not depend on the serialization of the contextual instance but rather on the need to serialize away the Contextual Reference (the proxy).
How does a typical proxy look like?
{code}
public class MailService$$CdiProxy extends MailService {
privte Bean<MailService> bean;
...
}
{code}
Now use this in the following class
{code}
@SessionScoped
public class User {
private @Inject MailService mailSvc;
...
{code}
The mailSvc is actually of type MailService$$CdiProxy. And this proxy needs the Bean<MailService> to be PassivationCapable, because the passivationId is the only way to re-attach to the Bean on the other side of the serialization.
Got me? This has no whatever connection to the actual scope of the contextual instance! If you need it or not only depends on the bean you inject it INTO (aka the bean containing the InjectionPoint).
> 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, 1 month
[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 resolved CDI-351.
---------------------------
Resolution: Done
Done
> 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, 1 month