Hi Michael, I guess that is the expected behavior...
Also: isn't this serialize and deserialize behavior the same if you use a session bean with a reference to an application bean? At least at the time when the session is serialized (e.g. cluster with session replication).. I suppose we could do something about it. Maybe introduce an init parameter which configures the following behavior: If such a bean is serialized, the mentioned references are set to null and then, when it is deserialized, they are injected again. However I don't know if this will be doable for session beans... Regards, Jakob 2010/1/17 Michael Kurz <[email protected]> > Hi, > > I just stumbled upon an issue regarding view scope I have not noticed > before. As the view scope map is stored in the view root it takes part in > state saving. My problem is this: I have a backing bean in view scope with > an application scoped bean injected by the managed bean creation facility. > As MyFaces serializes the state by default the bean is serialized and > deserialized on postback even with server side state saving. This also means > that the application scoped bean is serialized and deserialized which will > create a new instance of this bean which should be unique. > > I can handle this with turning off serialization for server state saving or > with making the property transient and loading it again in readObject(), but > is this really handy for end users? But then on the other hand I guess this > is exactly the expected behavior. Should/could we do something about that? > > Another question in this context: why is serialization and compression on > server state enabled by default? > > regards > Michael >
