Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 75370 invoked from network); 12 Feb 2000 21:29:16 -0000 Received: from cindy.kollegienet.dk (HELO odense.kollegienet.dk) (qmailr@130.226.80.138) by locus.apache.org with SMTP; 12 Feb 2000 21:29:16 -0000 Received: (qmail 20994 invoked from network); 12 Feb 2000 21:29:14 -0000 Received: from unknown (HELO kaa.hco.kollegie.dk) (root@172.16.8.10) by cindy.kollegienet.dk with SMTP; 12 Feb 2000 21:29:14 -0000 Received: from hco.kollegienet.dk (n1203aa.hco.kollegie.dk [172.16.9.132]) by kaa.hco.kollegie.dk (8.8.7/8.8.7) with ESMTP id WAA26920 for ; Sat, 12 Feb 2000 22:29:12 +0100 Message-ID: <38A5CFB1.B161A635@hco.kollegienet.dk> Date: Sat, 12 Feb 2000 22:25:05 +0100 From: Eugen Kuleshov X-Mailer: Mozilla 4.61 [en] (OS/2; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: Servlet reloading? References: <200002122012.MAA02321@clearink.com> <38A5CC2B.AAB105C7@gefionsoftware.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hans Bergsten 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 solved...at 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. Exactly! Eugen Kuleshov.