Bosun (SCJP, SCWCD).
So much trouble in the world -- Bob Marley
Tough in space?, <a href="http://tjws.sf.net" target="_blank" rel="nofollow">Get J2EE servlet container under 150Kbytes here</a><br />Love your iPod and want it anywhere?<a href="http://mediachest.sf.net" target="_blank" rel="nofollow">Check it here.</a><br /><a href="http://7bee.j2ee.us/book/Generics%20in%20JDK%201.5.html" target="_blank" rel="nofollow">Curious about generic in Java?</a><br /><a href="http://7bee.j2ee.us/bee/index-bee.html" target="_blank" rel="nofollow">Hate ant? Use bee.</a><br /><a href="http://7bee.j2ee.us/addressbook/" target="_blank" rel="nofollow">Need contacts anywhere?</a><br /><a href="http://searchdir.sourceforge.net/" target="_blank" rel="nofollow">How to promote your business with a search engine</a>
SRV.2.3.4 End of Service
The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a number of days, months, or years), or any amount of time in between.
When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the container may do this when it wants to conserve memory resources, or when it is being shut down.
Before the servlet container calls the destroy method, it must allow any
threads that are currently running in the service method of the servlet to complete execution, or exceed a server-defined time limit.
Once the destroy method is called on a servlet instance, the container may
not route other requests to that instance of the servlet. If the container needs to enable the servlet again, it must do so with a new instance of the servlet�s class.
After the destroy method completes, the servlet container must release the
servlet instance so that it is eligible for garbage collection.
Tough in space?, <a href="http://tjws.sf.net" target="_blank" rel="nofollow">Get J2EE servlet container under 150Kbytes here</a><br />Love your iPod and want it anywhere?<a href="http://mediachest.sf.net" target="_blank" rel="nofollow">Check it here.</a><br /><a href="http://7bee.j2ee.us/book/Generics%20in%20JDK%201.5.html" target="_blank" rel="nofollow">Curious about generic in Java?</a><br /><a href="http://7bee.j2ee.us/bee/index-bee.html" target="_blank" rel="nofollow">Hate ant? Use bee.</a><br /><a href="http://7bee.j2ee.us/addressbook/" target="_blank" rel="nofollow">Need contacts anywhere?</a><br /><a href="http://searchdir.sourceforge.net/" target="_blank" rel="nofollow">How to promote your business with a search engine</a>
Originally posted by Ben Souther:
How do you know the destroy method is not being called?
Originally posted by Ben Souther:
I would first check that the init and destroy method are being called.
Use System.out.println not log4j.
Yep. This is done. Servlet loads on startup just fine (all the logging in the init() method is showing up in the logs without a problem).If you can't hit the servlet with a browser, you'll need to use the load-on-startup attribute in the servlet entry of your web.xml page.
If both are working with System.out.println, then you may need to fish for a problem with your log4j configuration.
Confirmed. This was the problem. I loaded Log4J in the regular way, without using the Spring listener, and the problem went away.So, by unloading the Spring framework (which maybe happens before the destroy() method is called), I might be unloading log4J as well.
Originally posted by Philippe Desrosiers:
Any idea where the System.out.println would output to?
I'm doing laundry! Look how clean this tiny ad is:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
|