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<http://docs.oracle.com/javaee/6/api/javax/enterprise/inject/spi/B...
or
Contextual<http://docs.oracle.com/javaee/6/api/javax/enterprise/contex...
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 <
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev