> asking for trouble. If you need it to behave like a session-scoped > bean, then you probably should make it session-scoped, and just remove > it from your session when you're done with it.
Thanks Mike, I already follow this approach... Regards, Matthias > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Mike Kienenberger > Gesendet: Mittwoch, 18. Januar 2006 17:35 > An: MyFaces Discussion; [EMAIL PROTECTED] > Betreff: Re: AW: t:saveState flaw > > > Matthais, > > One thing to remember here is that t:saveState doesn't make a > request-scoped bean into a "page-scoped" bean. > > What it does is create an identical request-scoped bean on the next > request. Ie, it saves the state, not the bean :) > > If you play around in the guts of Serialization, you might be able to > use replaceObject to make it behave differently, but you're probably > asking for trouble. If you need it to behave like a session-scoped > bean, then you probably should make it session-scoped, and just remove > it from your session when you're done with it. > > On 1/18/06, Werner Punz <[EMAIL PROTECTED]> wrote: > > Matthias Kahlau schrieb: > > > > > I didn't know that "deserialization" means getting a new > object. That means > > > that after deserialization of the request-scoped > Backing-Bean, its reference > > > to the domain model object points to a new instance, and not > to the domain > > > model object which is still referenced by the session-scoped > Backing-Bean > > > which initially delegated the model update. > > > > > In case of a request scoped bean definitely yes, the old request bean is > > basically lost to the system a new one is filled into the place where it > > is held for el referencing. > > All beans serialized with it should also get a new instance, during > > deserialisation. > > > > > > > > One could consider this as a flaw of t:saveState or not. I think the > > > important point is that one must be aware of the fact that > > > > It is not directly a flaw it is more how serialisation and request scope > > works together. > > > > > serialization/deserialization of a Backing-Bean performed by using > > > t:saveState means that the references of the Backing-Bean point to new > > > instances after the deserialization. > > > > > In case of a request scoped bean yes, I dont know how it behaves with > > session scoped beans, because saveState is useless there anyway. > > Savestate is basically a mechanism to extend the scope of request scoped > > beans to scopes bigger than request and smaller than session. > > > >
