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

Romain Manni-Bucau rmannibucau at gmail.com
Mon Mar 18 14:52:59 EDT 2013


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
 or Contextual<http://docs.oracle.com/javaee/6/api/javax/enterprise/context/spi/Contextual.html>
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 <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

2013/3/18 Mark Struberg <struberg at yahoo.de>

> 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
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20130318/13d731c2/attachment.html 

More information about the cdi-dev mailing list