Re: [Tomahawk] about t:saveState usage on serializable objects

[Renzo Tomaselli]

Simon, great, now it's clear - many thanks. I use server-side saving and one point in your answer explains me why - after restarting Tomcat from within Eclipse and apparently randomly - I got an exception about a class of mine not being serializable. Not reproduceable, but I guess there was some timeout and a server attempt to restore a session. Btw, I noticed your reference to server-clustering. Months ago, I posted a request for info about any relationship between JSF and clustering. No answer though :-( Any more pointer would be appreciated, I miss the connection point between JSF session topics (state saving, session-scoped beans, etc.) and server clustering. Thanks, -- Renzo Simon Kitching wrote: ---- Renzo Tomaselli <[EMAIL PROTECTED]> schrieb: Hi all, I'm using t:saveState since a couple of years and it'd fine. However I'm a bit confused about the point of having saved objects as being serializable or not. Usually I save serializable objects, but from my debugger it seems that they are saved as they are - not serialized. And as such they are simply retrieved. Would anybody clarify this topic once forever ? Is serializability a true requirement ? If you use client-side state, then they must be serializable. The viewtree needs to be sent to the browser as a hidden field. JSF components implement a custom compressed state-saving mechanism, but any other objects are sent as their serialized version. And if you use server-side state plus server-clustering then they must be serializable. A user's session is sent to other members of the cluster as a serialized representation of the HttpSession. And if you want to use the "hot restart" feature of some servlet engines, where the webapp can be stopped then restarted without users losing their current state then they must be serializable. The HttpSession for every user is serialized and saved to a file, then reloaded after webapp restart. Otherwise, no :-) Well, actually I thought that myfaces serialized the viewstate by default, even when using server-side state, mainly in order to catch exactly this case where people didn't realise that stuff attached to the view should be serializable. I guess I remembered wrong, though, as you say it is not happening... Regards, Simon Regards, Simon