We had a similar problem. We had several variants of cayenne.xml and one was chosen by our model code at run-time. However Tomcat by default serializes sessions and recreates them at start-up, before our code gets a chance to do its thing. We had an instance of our model stored in the Visit, which of course is stored in the session, so Tomcat tried to recreate it.
A couple of possible fixes: If you have such an instance variable stored in the visit/session, make sure it's marked transient. Disable Tomcat's session persistence. 2009/10/30 Miloš Bielik <[email protected]> > Hi cayenne users > > We do not use default cayenne shared configuration approach. We use more > cayenne FileConfiguration-s in our webapp development (have to merge > more domains manually in the runtime: framework's with custom), > cayenne.xml files are stored in different locations not in the classpath. > > Webapp works fine. But when web container (Tomcat) reloads or migrates > sessions (eg. to another instance) HttpSessions are > serialized/deserialized. At this moment our *sesion scoped* DataContext > is trying to wake up from deserialization, unfortunatelly it tries to > init default shared configuration. Of course, exception is thrown. > > How can we make DataContext instances re-initialize correctly and bind > to our custom configuration? > > -- > Milos White Bielik > > >
