Wow, mine eye's have been opened! I had always thought it was just individual servlets that were reloaded. In this case I guess I can live with destroying everything on reload, because the stuff I wanted to keep up is stored in the ServletContext.
Thanks for the clarification, Mark Craig R. McClanahan wrote: > > On Wed, 3 Apr 2002, Mark Diggory wrote: > > >>Date: Wed, 03 Apr 2002 12:24:31 -0500 >>From: Mark Diggory <[EMAIL PROTECTED]> >>Reply-To: Tomcat Users List <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED] >>To: Tomcat Users List <[EMAIL PROTECTED]> >>Subject: Re: Servlet Destroy Method.... >> >>Yes I was looking to "not do something" in the destroy() method if its >>just the case that the servlet is being reloaded by the server. >>Otherwise, if the server was actually going through a shutdown process >>then I want my destroy() method to do something. >> >> > > Java doesn't have any means to replace an existing class. So, when Tomcat > does a reload to reflect your updated servlet or bean class, it has to: > - Shut down the entire webapp > - Throw away the webapp class loader and all the classes > that were previously loaded from /WEB-INF/classes and /WEB-INF/lib > - Restart the entire webapp > > Given this, there is basically no difference between what Tomcat does on a > reload versus a normal shutdown (except, of course, for the fact that the > app is not restarted again). There also isn't anything you could really > do differently even if you knew which kind of shutdown it was, because the > rest of the webapp is getting thrown away as well as the class you just > recompiled. > > >>-Mark >> >> > > Craig > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
