myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Serialization issue with app scoped beans referenced by session scoped beans
Date Thu, 07 Feb 2008 07:18:18 GMT
Hi Simon,

Spring's <aop:scoped-proxy/> might help - if it is serializable, and
retrieves the beanFactory on deserialization. However, it doesn't do
it right now; I think - but we discussed with J├╝rgen once, and maybe
it will be supported in the future.

I doubt the JSF managed-bean facility is sophisticated enough so that
an addition like this makes sense.

regards,

Martin

On Feb 7, 2008 8:13 AM, simon <simon.kitching@chello.at> wrote:
>
> 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
>
>



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message