11:14 a.m.
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
11:49 a.m.
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
12:13 p.m.
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
4472
days inactive
4474
days old
2 comments
3 participants
participants (3)
-
Jozef Hartinger -
Mark Struberg -
Pete Muir