[weld-issues] [JBoss JIRA] (WELD-1076) Deal with non-serializable dependent instances of a passivation capable bean

Deal with non-serializable dependent instances of a passivation capable bean ---------------------------------------------------------------------------- Key: WELD-1076 URL: https://issues.jboss.org/browse/WELD-1076 Project: Weld Issue Type: Task Affects Versions: 2.0.0.Alpha1 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.2.0.Beta1, 2.0.0.Alpha2 Since https://github.com/jboss/cdi/pull/47 it is legal for a normal-scoped component to have a non-passivation capable dependency, e.g: {CODE:JAVA} @SessionScoped public class Foo implements Serializable { @Inject public Foo(Bar bar) { } } public class Bar { } {CODE} Although the Bar instance reference is not retained by the Foo instance, the Bar instance is still technically a dependent instance of Foo and therefore the container needs to keep a reference to it in order to eventually destroy it properly. This is a problem because dependent instances of a bean are currently supposed to be serialized together with the normal-scoped instance but the Bar instance is not serializable. We may work around by making use of the following part of the spec: {QUOTE} Finally, the container is permitted to destroy any @Dependent scoped contextual instance at any time if the instance is no longer referenced by the application (excluding weak, soft and phantom references)." {QUOTE} and destroy every non-serializable dependent bean instance of a normal-scoped bean when the creational context for the normal-scoped bean instance is serialized. This is not 100% equivalent to "the instance is no longer referenced by the application" however covers all the sensible cases including: * Foo no longer holds a reference to Bar, therefore we can safely destroy Bar * Foo holds a reference to Bar - does not matter if we destroy Bar prematurely or not since serialization of Bar is going to fail anyway * Foo holds a reference to Bar in a transient field and is therefore either going to "forget" the reference no serialization (therefore we can destroy it) or is able to recreate the Bar instance itself on deserialization