[
https://issues.jboss.org/browse/WELD-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12684393#comment-12684393
]
Jozef Hartinger commented on WELD-1076:
---------------------------------------
Alternatively, we should not use creational context to store dependent
instances that do not define @PreDestroy callbacks nor are they intercepted by
a @PreDestroy interceptor.
> 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: 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
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues