DO NOT REPLY [Bug 3733] New: - session serialization problem

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3733

session serialization problem

           Summary: session serialization problem
           Product: Tomcat 4
           Version: 4.0 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: jon@latchkey.com


After a bunch of headbanging, I *think* I may have found the problem I 
have been having for a while now with regards to session serialization 
within Catalina. I don't have email access right now, so I'm reporting it 
here...

The problem it seems is that the order of session de-serialization is not 
correct (it isn't dictated by the servlet api, so this is understandable), it 
should execute something like this:

#1. serialize sessions
#2. servlet.destroy()
#3. servlet.init()
#4. de-serialize sessions

Instead, it seems to be executing like this:

#1. serialize sessions
#2. servlet.destroy()
#3. de-serialize sessions
#4. servlet.init()

Note that #1 and #2 may be reversed. I'm not sure. What I care about is 
that #3 and #4 seemed to be mixed up. 

The problem is that I have some static initializers that should be called for 
a few classes in the servlet's init() method. However, they do not seem to 
be called yet because static methods in those classes which rely on 
static data are null because the static init() methods for those classes 
have not yet been called by the servlet's init() method.

I hope that made sense. Remy or Craig, can you please tell me what the 
current ordering is? If it is the case that the init() method is called *after* 
the sessions are de-serialized, then that is the bug and that is bad for me.


thanks,

-jon