Status: Resolved (View Workflow)
Affects Version/s: 2.0.0.Alpha1
Similar Issues:Show 10 results
WELD-994 Passivating Beans do not allow Injection of non-serializable Instance injections WELD-1420 UnserializableDependencyException misleading message text if the problem is passivation capability WELD-1048 Decorated dependent bean not passivation capable WELD-537 More details to WELD-000072 Managed bean declaring a passivating scope must be passivation capable. WELD-1288 Incorrect validation of a decorator applied to built-in bean Instance WELD-1273 Validate that decorators of built-in beans are passivation capable dependencies WELD-1233 Improve error message for passivating bean with a non-passivation-capable interceptor/decorator WELD-14 Check passivating bean's interceptors are passivation capable WELD-1033 Injected Bean metadata not passivation capable WELD-1115 UnserializableDependencyException with dependency on SLSB
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:
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:
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)."
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