[cdi-dev] what Bean<T> implementations need to be PassivationCapable?

Pete Muir pmuir at redhat.com
Sat Mar 23 12:13:01 EDT 2013


On 18 Mar 2013, at 18:02, Mark Struberg <struberg at yahoo.de> wrote:

> 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.

No, the container will treat this as a deployment problem, as 6.6.4 says:

If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean … 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.

and 6.6.1 says:

A custom implementation of Bean is passivation capable if it implements the interfacePassivationCapable.

We can see that the injected bean is NOT passivation capable, and therefore it's not possible to inject it into the bean with the passivating scope.

> 
> 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. 

Right, the situation you describe is a deployment failure.

> Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters?

No.

> 
> LieGrue,
> strub
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev




More information about the cdi-dev mailing list