what Bean<T> implementations need to be PassivationCapable?
by Mark Struberg
Hi!
By catching an issue we have with the custom Bean<T> implementations provided by Spring Data, I got aware of a possible issue with PassivationCapable.
Which Bean<T> need to implement PassivationCapable?
6.6.1 seem to indicate that only beans or passivating scopes need a PassivationCapable bean.
But in this case: how does a container implement the NormalScope proxies for such a Bean? Consider we inject such a Contextual Reference of such a Bean<T> (which does _not_ implement PassivationCapable), e.g. MyDataRepository into a @SessionScoped bean. And now clustering kicks in and we propagate our @SessionScoped bean to another node.
What happens with the proxy for MyDataRepository? How will it 'reconnect' to the correct Bean<T> on the other side of the cluster? Imo this is only possible if all Bean<T> properly implement PassivationCapable.
Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters?
LieGrue,
strub
11 years, 5 months
[JBoss JIRA] (CDI-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-360:
----------------------------------------
@Oliver: AppScoped are not stateless, can be used to handle registry too which are strongly stateful
@Josef: yes but in practise it often ends being serializable and the id is just used as serialization id + the passivation capable definition is linked to serializable even if it doesn't match 1-1
> 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
>
> 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-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-360:
-------------------------------------
The issue is not about requiring all normal-scoped bean definitions to be serializable. The issue is about whether all the normal-scoped Bean<?> objects should implement the PassivationCapable interface (in other words whether they should be assigned a unique identifier) or not.
> 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
>
> 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-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Oliver Gierke (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Oliver Gierke commented on CDI-360:
-----------------------------------
If the bean is stateless (and I think at least application.scoped CDI beans are considered to be stateless), what's the benefit of serializing the object instead of simply creating a fresh instance? If I can opt-in into serialization instead of reconstitution, fine. But if I am essentially forced to make *all* application components serializable that feels highly invasive.
Beyond that: that still doesn't solve the {{@Dependent}} scenario, which even seems to be the more problematic one.
> 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
>
> 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-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-360:
----------------------------------------
@Olivier: JSF spec (and some others) force serialization in some part of the lifecycle even if beans are AppScoped + AppScoped can be serialized for recovery stuff so it can make sense
> 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
>
> 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-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Oliver Gierke (JIRA)
[ https://issues.jboss.org/browse/CDI-360?page=com.atlassian.jira.plugin.sy... ]
Oliver Gierke commented on CDI-360:
-----------------------------------
Under which circumstances do you think an {{@ApplicationScoped}} bean needs to be serialized? I don't think it makes sense to strongly impose serializability on application components. On the other hand: with this ticket, components that are {{@Dependend}} scoped would not be forced to be serializable although it's probably even more likely they and up in a scope requiring serialization.
> 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
>
> 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
Problem with resolution of CDI-271 - Does not address original intent of issue (CDI-71)
by Lincoln Baxter
Hey Folks,
I've just (a little late,) come to review the solution that was implemented for CDI-271 [0] about 10 days ago. This was provided as an alternate solution to the lack of payload qualifier information (resulting in highly-coupled observer methods) originally requested in issues CDI-36 and CDI-71 [1] [2]. With this implementation, CDI-36 and CDI-71 are no longer resolved and should be re-opened.
However, it seems that the original intent of these issues, which was to make event payload qualifier information available to observer methods, has been missed with this latest implementation in CDI-271. (I think probably because the issue titles did not actually describe the real intent, other than CDI-71, so it was easy to forget).
The result is that only "origin information" (where the event was fired from, and qualifiers of that source) are retrievable, and payload information has again been lost. This makes it impossible to implement certain features reliably (as outlined in my comment on CDI-271).
While I do think that "origin information" is important to have, I think that it would be a big gap to once again omit the "payload information" that people have been asking for. I have proposed a solution to this in the comments of CDI-271, but would be happy to re-open a new issue if needed to resolve this.
I propose the following additional (psuedo-code) API to provide the necessary "payload information" that the original issues required. This would not require any changes to the implementation of CDI-271, as they are somewhat orthogonal concerns actually (so we got another feature for "free' with CDI-271), but we still need something like this:
My recommendation would be to add another Interface like, "EventMetadata" that can be injected in place of InjectionPoint in your examples above:
public void handleEvent(@Observes @Any Object event, EventMetadata ip)
{
}
Where EventMetadata allows for operation such as:
/**
* Provides meta-information about an observed event payload. Can be retrieved as a parameter of an @Observes method.
*/
public interface EventMetadata {
/**
* Returns the set of qualifiers with which the corresponding event payload was fired.
*/
public Set<Annotation> getQualifiers();
/**
* Returns the Event<?> InjectionPoint from which this payload was fired, or null if it was fired from BeanManager.fireEvent(...);
*/
public Set<Annotation> getInjectionPoint(); // maybe? not really necessary with 271 already implemented, but probably a good idea for consistency with other APIs in the spec?
}
This will not break backwards compatibility, since we are simply adding another injectable type for observer methods, and it is actually complimentary to the implementation provided in CDI-271, because we can now (through a null check,) determine if a bean was fired via an InjectionPoint or with the BeanManager. (But that could be backed out if we decide to go with the second method in the EventMetadata interface proposed above.)
Thoughts?
[0] https://issues.jboss.org/browse/CDI-271
[1] https://issues.jboss.org/browse/CDI-36
[2] https://issues.jboss.org/browse/CDI-71
--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter(a)redhat.com
"If you want something, you'll find a way; if you don't, you'll find an excuse."
11 years, 5 months
[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 updated CDI-360:
------------------------------
Priority: Blocker (was: Major)
> 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
>
> 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-360) NormalScoped Bean<T> should all be forced to implement PassivationCapable
by Mark Struberg (JIRA)
Mark Struberg created CDI-360:
---------------------------------
Summary: 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
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-355) Disconnect between other specs and CDI with regard to when Interceptors and decorators are run
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-355?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-355:
-------------------------------
JJ, the addition to the spec was:
"a method of a bean via a non-contextual reference to the bean, if the instance was created by the container (e.g. using +InjectionTarget.produce()+ or +UnmanagedInstance.produce()+),"
> Disconnect between other specs and CDI with regard to when Interceptors and decorators are run
> ----------------------------------------------------------------------------------------------
>
> Key: CDI-355
> URL: https://issues.jboss.org/browse/CDI-355
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Joe Bergmark
> Assignee: Pete Muir
> Fix For: 1.1.FD
>
>
> Other specifications have text that appears to assume interceptors will run for non-contextual instances.
> The PDF (and CDI 1.0 for that matter) list the following rules to be considered a business method:
> 7.2
> Container invocations and interception [biz_method]
> When the application invokes:
> • a method of a bean via a contextual reference to the bean, as defined in Section 6.5.3, or
> • a business method of a session bean via an EJB remote or local reference,
> and then say:
> If, and only if, an invocation is a business method invocation:
> • it passes through method interceptors and decorators, and
> • in the case of a session bean, it is subject to EJB services such as declarative transaction management, concurrency, security
> and asynchronicity, as defined by the EJB specification.
--
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