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

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&gt; >To: Mark Struberg <struberg(a)yahoo.de&gt; >Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >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&gt; > >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 &gt;&gt;cdi-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > >

From: Pete Muir <pmuir(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: Romain Manni-Bucau <rmannibucau(a)gmail.com>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Tuesday, March 19, 2013 12:43 PM Subject: Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable? 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&gt; 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&gt; >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >> 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&gt; >> >> 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

On 18 Mar 2013, at 18:02, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > 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. No, the container will treat this as a deployment problem, as 6.6.4 says: If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean … has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, ... or has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not a dependent scoped bean and that is not a passivation capable dependency. and 6.6.1 says: A custom implementation of Bean is passivation capable if it implements the interfacePassivationCapable. We can see that the injected bean is NOT passivation capable, and therefore it's not possible to inject it into the bean with the passivating scope. > 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. Right, the situation you describe is a deployment failure. > Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters? No. > 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

From: Pete Muir <pmuir(a)redhat.com&gt; To: Jozef Hartinger <jharting(a)redhat.com&gt; Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Monday, March 25, 2013 12:49 PM Subject: Re: [cdi-dev] what Bean<T> implementations need to be PassivationCapable? G ot it, we've added the word dependency into 6.6.4 by mistake I think. On 25 Mar 2013, at 09:37, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > Pete, > > your argumentation is applicable if the custom Bean<?> implementation was @Dependent. I think that Mark is talking about a normal-scoped custom Bean<?> implementation. For this case the spec says: > > A custom implementation of Bean is a passivation capable dependency if it implements PassivationCapable *or if getScope() > returns a normal scope type*. > > Which means that the Bean<?> implementation does not need to implement PassivationCapable if it has a normal scope and still it will be a passivation capable dependency. > > On 03/23/2013 05:13 PM, Pete Muir wrote: >> On 18 Mar 2013, at 18:02, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> >>> 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. >> No, the container will treat this as a deployment problem, as 6.6.4 says: >> >> If a managed bean which declares a passivating scope, a stateful session bean which declares a passivating scope, or a built-in bean … has a non-transient injected field, bean constructor parameter or initializer method parameter which is not annotated with @TransientReference and that resolves to a dependent scoped bean that is not a passivation capable dependency, ... or has a non-transient injected field, bean constructor parameter or initializer method parameter that resolves to a bean that is not a dependent scoped bean and that is not a passivation capable dependency. >> >> and 6.6.1 says: >> >> A custom implementation of Bean is passivation capable if it implements the interfacePassivationCapable. >> >> We can see that the injected bean is NOT passivation capable, and therefore it's not possible to inject it into the bean with the passivating scope. >> >>> 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. >> Right, the situation you describe is a deployment failure. >> >>> Or should we use the bean type + qualifiers to create a synthetic passivationId? Does this hold waters? >> No. >> >>> 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 >