[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: Rejected
Unfortunately this was a bug in CDI 1.0 - not all session beans are passivation capable, so CDI assuming they are is just plain wrong.
> @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, 5 months
[JBoss JIRA] (CDI-354) Inappropriate payload of the @Initialized(ConversationScoped.class) event
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-354?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-354.
---------------------------
Resolution: Done
Done.
I've also updated the events for the application, request and session contexts to match, and pass the actual object, not the Event.
> Inappropriate payload of the @Initialized(ConversationScoped.class) event
> -------------------------------------------------------------------------
>
> Key: CDI-354
> URL: https://issues.jboss.org/browse/CDI-354
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Contexts
> Affects Versions: 1.1.PFD
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Blocker
> Fix For: 1.1.FD
>
>
> {quote}
> An event with qualifier @Initialized(ConversationScoped.class) is fired when the conversation context is initialized
> and an event with qualifier @Destroyed(ConversationScoped.class) is fired when the conversation is destroyed.
> The event payload is:
> • the conversation id if the conversation context is destroyed and is not associated with a current Servlet request, or
> • the ServletRequestEvent if the application is a web application deployed to a Servlet container, or
> • any java.lang.Object for other types of application.
> {quote}
> The conversation context is supposed to be activated in a container-provided filter with the name "CDI Conversation Filter". A Servlet Filter itself does not have access to a ServletRequestEvent instance (that is only available to ServletRequestListeners). Therefore, the implementation would either have to re-create the instance by combining ServletRequest and ServletContext or propagate the ServletRequestEvent from a ServletRequestListener.
> From an application point of view, ServletRequest is the only interesting property of ServletRequestEvent anyway. Therefore, I suggest to change the wording of the spec to specify ServletRequest (or HttpServletRequest) as the payload of @Initialized(ConversationScoped.class) and @Destroyed(ConversationScoped.class) events.
--
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, 5 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 updated CDI-360:
--------------------------
Fix Version/s: 1.1.FD
> 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, 5 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:
-------------------------------------
No, this issue is about decorators mostly.
> 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, 5 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-361?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-361 at 3/27/13 9:59 AM:
------------------------------------------------------------
this is almost the same like CDI-360, isn't?
was (Author: struberg):
this is the same like CDI-360.
> 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, 5 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:
--------------------------------
Description:
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.
was:
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 on required 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.
> 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, 5 months
[JBoss JIRA] (CDI-361) Issues with passivation capable beans and dependencies
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-361:
-----------------------------------
Summary: 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 on required 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, 5 months