Re: [cdi-dev] Dealing with non-passivation-capable dependencies of a normal-scoped bean
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(a)redhat.com>
To: Jozef Hartinger <jharting(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)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(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