myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yee CN <ye...@streamyx.com>
Subject RE: Session Scope Bean does NOT require serialization. Myfaces bug?
Date Mon, 19 Dec 2005 22:54:00 GMT
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. So is 1.1.1 equivalent to
SERIALIZE_STATE_IN_SESSION=false? Where was the state being saved then?

Thanks taking time to explain - perhaps this should go to myfaces wiki?

Regards,
Yee

-----Original Message-----
From: Simon Kitching [mailto:skitching@obsidium.com] 
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


Mime
View raw message