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

[Jozef Hartinger]

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