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

[Mark Struberg]

I think the issue is the 'OR' in the wording of 6.6.2. 

Without the Bean<?> having a passivationId we cannot reference them in our proxies -> we cannot serialize the proxies properly :(

LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Jozef Hartinger <jharting at redhat.com>
> Cc: Mark Struberg <struberg at yahoo.de>; cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Monday, March 25, 2013 12:49 PM
> Subject: Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable?
> 
>G ot 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
>> 
>