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.
2013/3/18 Mark Struberg
<struberg@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev