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

________________________________ From: Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Monday, March 18, 2013 7:52 PM Subject: Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable? Hi just to share my point of view on it (alread ydiscussed with Mark): javadoc and spec both state this interface "Indicates that a custom implementation of Bean or Contextual is passivation capable." so a bean which doesn't impl it will not be passivation capable. From my understanding it means the proxy can't be serialized/unserialized without side effects. If it is not the case then this interface would be useless. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2013/3/18 Mark Struberg <struberg(a)yahoo.de&gt; 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. > >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. >Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters? > >LieGrue, >strub > >_______________________________________________ >cdi-dev mailing list &gt;cdi-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev >