Hi Ted, Something like that happened to me recently, and it turns development into a tedious task as you have to re-login every time. The usual cause, as you mentioned, is that you probably store something in some session or in the context that is not serializable. The fact that you can store it in the session or in the context doesn't mean that it is serializable, and sometimes you don't even get a proper error message. In my case, I had stored a reference to the servlet context to an object that was being kept in the context. As the servlet context is not serializable, all the sessions and application state was being thrashed every time I redeployed. With orion 1.4.8, I was getting an "application state not serializable: com.orion...HttpApplication" error. With orion 1.5.2, I was getting NO ERROR, and it silently ignored the previous state. In the end, I re-checked all the attributes of all the classes that were being stored in the sessions and in the context and I found it. It's not an easy problem to follow, I wish there were better means to track this down. I queried the list and I got no answer so I guess there isn't a way of getting more information about the process. Good luck, it it worked before and now it doesn't, track the changes you have made to the classes added to the sessions and the context and remember that a class is only serializable if all its RUNTIME non-transient members are also serializable (apart of the small detail of implementing the serializable interface, of course ;) ). Watch out for hashtables, vectors and the like, they can hide non-serializable instances. regards, D.
"Rice, Ted" wrote: > i have read, and re-read, all > of the postings on class > (re)loading in relation to deployed > applications inside orion. yet, i still > have some unanswered questions. > > in my past experience, compiling classes > to the ./WEB-INF/classes directory and > touching either the web.xml or application.xml > file will cause the new classes to be > picked up and used. all objects that are > in session are serialized and available > after the application is re-deployed without > having to re-start orion. > > however, i am now experiencing a situation > wherein i'm losing my session information and > being forced to re-login to my application to > continue development. > > is there a set of criteria or implemenation details > i'm missing. all objects are obviously serializable > or they would not be able to be stored in a session. > yet, my latest encounters with class reloading makes > me doubt this assertion. > > any ideas/paths i can explore to making my > development life less hell-like? > > thanks, > > ted rice
