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

[Pete Muir]

Got it, we've added the word dependency into 6.6.4 by mistake I think.

On 25 Mar 2013, at 09:37, Jozef Hartinger <jharting at redhat.com> wrote:

> Pete,
> 
> your argumentation is applicable if the custom Bean<?> implementation was @Dependent. I think that Mark is talking about a normal-scoped custom Bean<?> implementation. For this case the spec says:
> 
> A custom implementation of Bean is a passivation capable dependency if it implements PassivationCapable *or if getScope()
> returns a normal scope type*.
> 
> Which means that the Bean<?> implementation does not need to implement PassivationCapable if it has a normal scope and still it will be a passivation capable dependency.
> 
> On 03/23/2013 05:13 PM, Pete Muir wrote:
>> 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
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>