On Wed, 2008-02-06 at 19:20 -0800, Kent Tong wrote: > > > Simon Kitching-4 wrote: > > > > And java's serialization has *always* discarded transient objects on > > serialization and marked them as null on deserialization. That's > > perfectly normal. There are a number of options here for you, including > > transient Bean2 appBean = new Bean2(); > > or accessing it only via a getBean2() method that checks whether it is > > null and restores it, or implementing custom serialization for Bean1. > > > > Thanks for the reply. My point is that JSF allows injecting an application > scoped bean into a session scoped bean. As this is the only way to give > the latter access to the former without code pollution, this should be > the recommended way suggested by JSF. However, due to the problem > raised above, in fact the recommended way is not really working.
That's a fair point. When a property of a session-scoped bean has been set to an app-scope bean via dependency-injection, it is difficult to restore it on deserialize. As you say, it really should be transient because you don't want to store a copy of the app-scope bean during serialization of an http session, and probably don't want a private copy to be created on deserialize (but instead be relinked back to the shared app-scope instance). It's particularly a problem for distributed sessions. But there is no way AFAIK to cause the dependency to be reinjected on deserialize. The bean can be "looked up", but (a) that is ugly code, and (b) breaks the whole point of dependency injection. Perhaps injection via annotations will work here; the injection process could be run against beans after the session is deserialized. Of course this does only apply to the fairly rare case of injecting an app-scope reference into a session-scoped bean. I cannot see any similar problems when injecting session-scope into session-scope, or anything into a request-scoped bean. As a hack, I suppose you could write your own HttpSessionActivationListener that reinjects stuff based on annotations in classes. I'm not sure what the JSF spec has to say about this issue... Regards, Simon
