Throwing it on a slight tangent, but maybe storing the objects in the session isn't the best solution. I've done it in the past, but have found that it's often more trouble than it's worth.
I would do instead is either inject a Zend_Session_Namespace to store object data, or create a mapper that maps it to the session. The advantages of this is: 1. You don't need to load class definitions for each requests (even if you don't need them) 2. You can set up a sub-system that uses the same session that is otherwise comepletely independent. 3. You can change the class definition without killing your session. You might still get errors, but if you're smart with the mapper, you can automatically migrate the session data from the old class definition to the new one. basically means you can update the live site without having to wipe all your user's sessions. no.3 is probably the biggest reason for not storing standard objects in the session. If you do end up storing them in the session, make sure you clear all sessions after doing an update. Otherwise the user will be unable to access the site until the session expires, they clear their cookies, or use a different browser. Cheers, David -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/problem-with-autoloading-class-definition-for-serialization-and-deserialization-tp3062477p3062973.html Sent from the Zend Framework mailing list archive at Nabble.com.
