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&gt; 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