I can't reproduce this (ok, I'm lying, if you re-order "server.xml" enough, you can do it :). But I can't find a valid case where this occurs.
I've reversed the check between "Serialize", and "Copy" so that your previous Hashtable example should now work. ----- Original Message ----- From: "Hugh J. L." <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Sunday, August 25, 2002 7:02 PM Subject: Re: It seems new Tomcat33 reloading has a ClassLoader problem > When I was tracing into ObjectSerializer, I found that > the class loader parameter it got was NOT the one > passed to it in SimpleSessionStore. So the > serialization was NOT done using our expected context > class loader of the new context. > > Why? I can't explain this behavior... > > I simulated the serialization process in a servlet, > which was loaded by the new context class loader as a > matter of course, it worked well and the servlet could > access the old object after serialization. > > Don't know if these clues are useful to you. > > Regards, > Hugh > > --- Bill Barker <[EMAIL PROTECTED]> wrote: > > This is really going beyond Tomcat's ability to > > detect. Beans that want > > this much control will need to be life-cycle aware > > (e.g. implement > > javax.servlet.http.HttpSessionBindingListener). > > Alternatively, the Bean can > > re-load the class when serialized. > > > > That having been said, I'm not really happy with the > > life-cycle support on > > the current patch. It is currently too closely tied > > to the > > Intercepter/Facade split. I may make it cleaner > > later. > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
