tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: Servlet reloading?
Date Sat, 12 Feb 2000 21:10:03 GMT wrote:
> > > NOOOOO. I spent many many many many weeks getting this right in Apache
> > > JServ. Look at my code. There is a whole process that is done to serialize
> > > and de-serialize everything that needed to be serialized.
> >
> >   What about situation when some session saved classes changed?
> >   What about situation when reloaded servlets changing execution logic?
> > I mean new servlets no more needs (or needs another) data in session.
> >   Maybe better way is killing all session data for new servlets.
> >
> >   Eugen Kuleshov.
> No. I do not think you understand the problem I was talking about. The
> issue is simply put:
> Sessions are created within the AdaptiveClassloader scope. When you kill
> that classloader, the HttpSession objects (and all the objects within
> there) become invalid because Java objects are associated with their
> classloader.
> There is a way to "copy" those HttpSession objects into a new
> classloader by serializing them to an outputstream, (not a file or disk or
> whatever) and then de-serializing them from that same stream, but in the
> context of the new classloader instance. There are a
> few gotcha's that you have to consider when doing this, but I have the
> problem least within Apache JServ. Look at the source code. It
> is really quite clear.
> Essentially, it allows those session objects to remain valid even though
> their parent classloader was killed.

But don't you still have a problem if the class for one of the objects
in a session has been changed, for instance, an instance variable has been
removed or added? When you try to "copy" it into the new class loader, the
serialized format doesn't match the new class. And in some cases, like 
Eugen mentioned, the new version of the servlet may not even want the old
session data.

I have always looked at servlet reloading in general, with or without
trying to preserve the state of things in the session, as something that
only works in the most simple cases. To support application updates, at any
level, probably requires a new protocol between the server and the
application components (servlets, session beans, etc.) so they can decide
on a class by class basis what should be reloaded or not, and support
a more advanced way to restore state than simply serialize/deserialize.

Hans Bergsten
Gefion Software

View raw message