Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable?
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