[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 resolved CDI-360.
---------------------------
Resolution: Done
I made this change.
> 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-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
Please review very carefully.
> 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
[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 commented on CDI-334:
-------------------------------
I mislabeled the commit, it is https://github.com/jboss/cdi/commit/8b4ee579e9f438098a7366df063d02de0df9dc8c - please review carefully, but I believe this resolves all the remaining issues.
> 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
[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:
-------------------------------
Thats the change I proposed making :-)
> 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-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:
-----------------------------------
That sounds good to me.
Now we only need to fix the definition of Passivation Capable Bean in 6.6.2. This paragraph atm declares a Bean to be passivation capable if it either implements PassivationCapable OR it serves a NormalScope.
We should remove the 'NormalScope' part of this sentence.
> 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-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 commented on CDI-334:
-------------------------------
I don't really know what is wrong with 5.1.1.1.
5.2.2 and 5.3.1 are basically identical. There are two problems. One, I screwed up the definition of producers here, and secondly, I inadvetantly implied you needed to eliminate alternatives selected for the application in the first sentence. I will fix both.
> 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
[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 resolved CDI-361.
---------------------------
Resolution: Done
Merged
> 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
[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:
-------------------------------
An option would be to say that custom beans are not passivation capable dependencies unless they implement PassivationCapable which avoids breaking apps unnecessarily, and add a note to the spec that we recommend all Beans implement PassivationCapable. Then perhaps in CDI.next require it.
> 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-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
Switched to using classpath entries, which covers all these types of things.
> 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-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:
-------------------------------
Yes, Jozef explained it to me. I'll try to see if there are options. What you propose is, IMO, not an option, as it breaks a lot of apps that aren't injecting custom beans into passivating scoped beans.
> 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