i took care of my words ;)<div><br></div><div>the javadoc speak about Bean<?></div><div><br clear="all"><div><div><i>Romain Manni-Bucau</i></div><div><i>Twitter: <a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a></i></div>
<div><i>Blog: </i><a href="http://rmannibucau.wordpress.com/" target="_blank"><i>http://rmannibucau.wordpress.com/</i></a></div><div><i>LinkedIn: </i><font color="#0000ee"><i><u><a href="http://fr.linkedin.com/in/rmannibucau" target="_blank">http://fr.linkedin.com/in/rmannibucau</a></u></i></font></div>
<div><i><span style="background-color:rgb(255,255,255)">Github: </span><a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a></i></div><div><br></div></div>
<br><br><div class="gmail_quote">2013/3/18 Mark Struberg <span dir="ltr"><<a href="mailto:struberg@yahoo.de" target="_blank">struberg@yahoo.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
The question (once again) is whether the terminus 'bean' means the Bean<T>, the Contextual Instance or the Contextual Reference.<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
<br>
>________________________________<br>
> From: Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
>To: Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
>Cc: cdi-dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
>Sent: Monday, March 18, 2013 7:52 PM<br>
>Subject: Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable?<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
>Hi<br>
><br>
><br>
>just to share my point of view on it (alread ydiscussed with Mark):<br>
><br>
><br>
>javadoc and spec both state this interface "Indicates that a custom implementation of Bean or Contextual is passivation capable."<br>
><br>
><br>
>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.<br>
><br>
><br>
>If it is not the case then this interface would be useless.<br>
><br>
><br>
>Romain Manni-Bucau<br>
>Twitter: @rmannibucau<br>
>Blog: <a href="http://rmannibucau.wordpress.com/" target="_blank">http://rmannibucau.wordpress.com/</a><br>
>LinkedIn: <a href="http://fr.linkedin.com/in/rmannibucau" target="_blank">http://fr.linkedin.com/in/rmannibucau</a><br>
>Github: <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
><br>
><br>
><br>
><br>
>2013/3/18 Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
><br>
>Hi!<br>
>><br>
>>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.<br>
>><br>
>>Which Bean<T> need to implement PassivationCapable?<br>
>><br>
>>6.6.1 seem to indicate that only beans or passivating scopes need a PassivationCapable bean.<br>
>><br>
>>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.<br>
>><br>
>>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.<br>
>>Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters?<br>
>><br>
>>LieGrue,<br>
>>strub<br>
>><br>
>>_______________________________________________<br>
>>cdi-dev mailing list<br>
>><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>