Simon is right (as always!). But the new serialization stuff is not available in 1.1.1 only in current nightly (where it is waiting for the next release ;))
2005/12/20, Simon Kitching <[EMAIL PROTECTED]>: > Yee CN wrote: > > Simon, > > > > What exactly is "SERIALIZE_STATE_IN_SESSION=true/false" that is new in the > > nightly then? > > > > As far as I can tell - the 1.1.1 release was not serializing the bean I > > placed in t:saveState, but it does in the nightly. > > Yep, that seems right to me. > > > So is 1.1.1 equivalent to > > SERIALIZE_STATE_IN_SESSION=false? > > Yes, I believe so. > > > Where was the state being saved then? > > In 1.1.1, when server-side saving was enabled, I believe the VIEW state > was being saved simply by storing a reference to the UIViewRoot (and > hence all its children) in the session - unserialized. As long as the > webapp didn't have clustering or hot-deploy enabled, then the UIViewRoot > object was simply kept in memory until the next access. > > As described in the previous email, normal "managed beans" are not > affected by the view serialization process. However a bean referenced > from a t:saveState component does get stored in the same way as the > view. In 1.1.1, because server-side state saving simply stored by > putting a reference to the UIViewRoot into the session (ie no > serialization occurs), the bean that the t:saveState referred to wasn't > serialized. If you'd turned on client-side saving, then you would have > got the serialization failure in 1.1.1. > > Now I think you can get the same effect with > SERIALIZE_STATE_IN_SESSION=false, ie "don't serialize the state". > > However the new default is SERIALIZE_STATE_IN_SESSION=true, ie to run > the serialization process on the UIViewRoot, then store this serialized > data in the session instead of the original UIView component. This: > * Is more memory-efficient (though more CPU intensive) > * Makes behaviour consistent between client-side and server-side saving. > Formerly, an app that worked with server-side state might fail when > client-side was enabled because of serialization failures. > * Ensures that any app that works correctly will also be clusterable. > Formerly, an app might run on a single system but fail when clustering > was enabled. > > > > > Thanks taking time to explain - perhaps this should go to myfaces wiki? > > > > Yes, that would be a good idea. > > Note that I'm no expert in this area... > > Cheers, > > Simon > > > Regards, > > Yee > > > > -----Original Message----- > > From: Simon Kitching [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 20 December 2005 5:40 AM > > To: MyFaces Discussion > > Subject: Re: Session Scope Bean does NOT require serialization. Myfaces bug? > > > > Aleksei Valikov wrote: > >> Hi. > >> > >>> My understanding is that with R1.1.1 the session scoped beans are not > >>> serialized (thus Myfaces cannot be used in clustered deployments with > >>> shared > >>> sessions between containers). Serialization of backing beans to > >>> session is > >>> only added in the current build - and thus my questions regarding its > >>> performance. > >>> > >>> Please correct me if I am wrong. > >> I don't get it. Once you declare your bean as session-scoped, it simply > >> becomes a session attribute - and managed by the servlet container. It's > >> servlet container's task to serialize the session (together with its > >> attributes), not JSF's. MyFaces can check if all of your session-scoped > >> beans are serializable, but performing the serialization is above its > >> tasks. > >> > > > > MyFaces state-handling/serialization applies only to the view tree (ie > > UIComponent objects). > > > > With managed beans, the MyFaces state-handling is irrelevant; JSF > > doesn't try to "serialize backing beans". The beans simply go into the > > servlet engine's request, session or application scope as for a non-JSF > > application. Objects in the session don't need to be serializable, > > though things like clustering and hot-restart won't work if they are not. > > > > However when using t:saveState, the two worlds do meet, because that > > component is a UIComponent that gets stored along with the View, but it > > retains a reference to a managed bean that it serializes too. In this > > case the referenced bean *must* be Serializable (or implement > > StateHolder) as documented for the saveState component. > > > > > > Cheers, > > > > Simon > > > > > > > > -- Mathias
