A "bean" is a Bean<T>.
A contextual instance is a contextual instance, a contextual reference is a contextual
reference.
On 18 Mar 2013, at 19:55, Mark Struberg <struberg(a)yahoo.de> wrote:
The question (once again) is whether the terminus 'bean' means the Bean<T>,
the Contextual Instance or the Contextual Reference.
LieGrue,
strub
> ________________________________
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> 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>
>
> 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
>>
>
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev