[cdi-dev] Dealing with non-passivation-capable dependencies of a normal-scoped bean

[Mark Struberg]

Well, I guess we have 2 extremes.

The old solution did permit any non Serializable @Dependent instances as parameter to methods of passivation capable beans.

This was way too restrictive and did permit a lot of valid scenarios. Mostly all use cases where you need this dependent bean just to initialize other values. 

The other use case have been non-serializable transient @Dependent scoped beans. It's pretty common and completely valid to just provide an own writeObject/writeExternal + readers to properly serialize those members. 

But I see your point and you are right  about the problem this causes within the CreationalContext. Will need to think about this for a few hours... 

LieGrue,
strub


----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Jozef Hartinger <jharting at redhat.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Tuesday, March 6, 2012 5:49 PM
> Subject: Re: [cdi-dev] Dealing with non-passivation-capable dependencies of a normal-scoped bean
> 
> No, I hadn't thought of that.
> 
> Mark, others, any thoughts?
> 
> On 5 Mar 2012, at 16:14, Jozef Hartinger wrote:
> 
>>  Hello,
>> 
>>  with https://github.com/jboss/cdi/pull/47 in place the validation rules 
>>  for dependencies of normal-scoped components have been weakened. The 
>>  idea is that CDI should not enforce dependencies to be passivation 
>>  capable if these dependencies are only used temporarily in the 
>>  initialization of a normal-scoped bean. Consider the following example:
>> 
>>  @SessionScoped
>>  public class Foo implements Serializable {
>> 
>>     @Inject
>>     public Foo(Bar bar) {
>>     }
>>  }
>> 
>>  public class Bar {
>>  }
>> 
>>  CDI now considers this scenario to be valid. However, the Bar instance 
>>  is still technically a dependent instance of Foo and the container still 
>>  needs to retain a reference to it in order to destroy it properly. The 
>>  problem arises when the session is serialized. Although the Foo instance 
>>  does not reference the Bar instance and can therefore be serialized, the 
>>  CreationalContext of Foo still holds the dependent instance and is 
>>  therefore not serializable.
>> 
>>  I came up with an idea of how to implement it in Weld at 
>>  https://issues.jboss.org/browse/WELD-1076 . However, I do not consider 
>>  this approach to be very clean and intuitive for specification 
>>  implementors. Therefore, I want to make sure that the specification is 
>>  really intended to be implemented this way and that this is not an 
>>  oversight in the specification.
>> 
>>  JH
>>  _______________________________________________
>>  cdi-dev mailing list
>>  cdi-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>