[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 reassigned CDI-360:
-----------------------------
Assignee: Pete Muir
> 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
> Assignee: Pete Muir
> 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
[JBoss JIRA] (CDI-357) @Stateless and @Singleton session beans are no longer passivation capable dependencies
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-357?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-357.
---------------------------
Resolution: Done
Agreed, this will break passivation capable dependency validation. Spelled this out.
> @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
[JBoss JIRA] (CDI-348) Clarify which beans "have" bean defining annotations
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-348?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-348.
---------------------------
Resolution: Done
I've moved it to be bean class, not bean.
> 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
[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:
---------------------------------
Is splitting a package between the WEB-INF/classes directory of a war and a directory in the JVM classpath portable, then?
> 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
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-274.
---------------------------
Resolution: Done
> 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
> Labels: faq
> 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
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir reopened CDI-274:
---------------------------
> 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
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-274:
--------------------------
Labels: faq (was: )
> 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
> Labels: faq
> 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
[JBoss JIRA] (CDI-319) Reword part of the @Vetoed section
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-319?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-319.
---------------------------
Resolution: Done
No, jar is correct. The issue is that if you split a package between JARs then you have to do a 2 pass scan in order to find which types are in the package that was @Vetoed.
In general, it's not sensible to split packages across jars.
> 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
[JBoss JIRA] (CDI-356) Constructor-level interceptor bindings not considered
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-356?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-356.
---------------------------
Resolution: Done
Thanks. The sentence is removed, as you can now bind lifecycle interceptors to both constructors and lifecycle callback methods.
> Constructor-level interceptor bindings not considered
> -----------------------------------------------------
>
> Key: CDI-356
> URL: https://issues.jboss.org/browse/CDI-356
> Project: CDI Specification Issues
> Issue Type: Tracker
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> For example:
> {quote}
> If an interceptor for lifecycle callbacks declares an interceptor binding type that not defined @Target(TYPE), the container
> automatically detects the problem and treats it as a definition error.
> {quote}
> An interceptor that declares an @AroundConstruct interceptor method is an interceptor for a lifecycle callback yet it makes sense to define the binding as @Target(CONSTRUCTOR).
--
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
[JBoss JIRA] (CDI-356) Constructor-level interceptor bindings not considered
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-356?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-356:
---------------------------------
The quoted sentence is still present in CDI and creates a conflict.
> Constructor-level interceptor bindings not considered
> -----------------------------------------------------
>
> Key: CDI-356
> URL: https://issues.jboss.org/browse/CDI-356
> Project: CDI Specification Issues
> Issue Type: Tracker
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> For example:
> {quote}
> If an interceptor for lifecycle callbacks declares an interceptor binding type that not defined @Target(TYPE), the container
> automatically detects the problem and treats it as a definition error.
> {quote}
> An interceptor that declares an @AroundConstruct interceptor method is an interceptor for a lifecycle callback yet it makes sense to define the binding as @Target(CONSTRUCTOR).
--
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