[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 commented on CDI-334:
-------------------------------------
{quote}The container eliminates all eligible beans that are not alternatives selected for the bean archive or selected for the application, *except for producer methods and fields of beans that are alternatives*. If
* there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.
* 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 the highest priority value. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.
{quote}
Non-alternative producers defined on alternatives with priority are not eliminated initially but are forgotten later on.
> 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, 8 months
[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 commented on CDI-334:
-------------------------------------
{quote}An alternative may be given a priority for the application by placing the @Priority annotation on the bean class of a managed bean, session bean, producer method or producer field annotated with the @Alternative annotation.{quote}
As @Priority can only be applied to types it is unclear how an @Alternative producer may be given a priority. Is a priority of the bean class used in that case? This section needs to be expanded to specify producers explicitly.
> 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, 8 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-361:
-------------------------------------
Decorators of built-in beans still do not seem to be validated properly. If a non-passivation capable decorator decorates a built-in bean it should be an error.
> 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, 8 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger updated CDI-361:
--------------------------------
Comment: was deleted
(was: Typo:
{quote}a method parameter which resolves *to to* a bean that is a passivation capable bean{quote}
The same type of issue is in:
{quote}The container must use the final value of this property, after all observers have been called, as the only source of types and annotations for *the the* program elements.{quote}
Although unrelated to this issue I do not want to create another one for this simple typo.
)
> 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, 8 months
[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 updated CDI-334:
--------------------------------
Comment: was deleted
(was: The same type of issue is in:
{quote}The container must use the final value of this property, after all observers have been called, as the only source of types and annotations for *the the* program elements.{quote}
Although unrelated to this issue I do not want to create another one for this simple typo.
)
> 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, 8 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger reopened CDI-361:
---------------------------------
Typo:
{quote}a method parameter which resolves *to to* a bean that is a passivation capable bean{quote}
The same type of issue is in:
{quote}The container must use the final value of this property, after all observers have been called, as the only source of types and annotations for *the the* program elements.{quote}
Although unrelated to this issue I do not want to create another one for this simple typo.
> 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, 8 months
[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 updated CDI-334:
--------------------------------
Comment: was deleted
(was: Typo:
{quote}a method parameter which resolves *to to* a bean that is a passivation capable bean{quote})
> 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, 8 months
[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 commented on CDI-334:
-------------------------------------
The same type of issue is in:
{quote}The container must use the final value of this property, after all observers have been called, as the only source of types and annotations for *the the* program elements.{quote}
Although unrelated to this issue I do not want to create another one for this simple typo.
> 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, 8 months
[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:
---------------------------------
Typo:
{quote}a method parameter which resolves *to to* a bean that is a passivation capable bean{quote}
> 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, 8 months
[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:
---------------------------------
Actually, one more minor issue with this.
It would be cleaner better not to repeat the part about passivationCapable flag in multiple places and rather say that:
{quote}all stateful session beans which are passivation capable beans are passivation capable dependencies{quote}
Furthermore, the definition of passivation capable beans needs minor wording cleanup. It currently says:
{quote}
As defined by the EJB specification, all stateful session beans are passivation capable if:
interceptors and decorators of the bean are passivation capable, and,
the stateful session bean does not have the passivationCapable flag set to false.
{quote}
and should rather say:
{quote}
As defined by the EJB specification, *a* stateful session bean *is* passivation capable if:
interceptors and decorators of the bean are passivation capable, and,
the stateful session bean does not have the passivationCapable flag set to false.
{quote}
> @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, 8 months