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(a)redhat.com>
To: Jozef Hartinger <jharting(a)redhat.com>
Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)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(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>