Here is a response that I received from one of the members of the JSF team.
The file attachment is actually a gzipped zip file for some odd reason (not a tar file).
I asked him why the DataModels aren't Serializable to begin with. Hopefully, he'll respond. To me it seems completely counter-intuitive that they aren't.
Jon
----- Original Message ----- From: "Ed Burns" <[EMAIL PROTECTED]>
To: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 10, 2005 4:29 PM
Subject: DataModels not Serializable?
On Thu, 10 Mar 2005 10:12:57 -0600, Jonathan Eric Miller <[EMAIL PROTECTED]> said:
JEM> Up until I started using JSF, I always made my beans Serializable JEM> so that I could restart my Tomcat server and have it save and JEM> restore my session state. Since, DataModel isn't Serializable, I JEM> can't do this anymore. Are you saying that JSF internals don't JEM> serialize themselves, therefore, even if the DataModels were JEM> Serializable, it still wouldn't work (i.e. you can't restart Tomcat JEM> and expect a JSF application to continue to function remembering JEM> it's former state after the restart)?
The state management mechanism in Faces is only intended to save state across HTTP requests, not server invocations. If you happen to have your actual DataModel subclass in session scope, there's nothing preventing you from making your implementation implement Serializable.
I've modified the guessNumber example to use a managed bean that extends DataModel and implements Serializable. I tested that the bean persists in session across tomcat invocations. Therefore, I know it works.
Ed
Attached is the source you can overlay onto your jsf-demo repository.
--------------------------------------------------------------------------------
-- | [EMAIL PROTECTED] | {home: 407 294 2468, office: 408 884 9519 OR x31640} | homepage: | http://purl.oclc.org/NET/edburns/ | aim: edburns0sunw | iim: [EMAIL PROTECTED]
serializableDataModel.tar.gz
Description: GNU Zip compressed data
