cool down the hot deployment

when building webapps, most people agree that hot deployment is evil. it is common to observe some mem-leaking, even though you try to be very careful not to reference classes of the webapp´s classloader from the outside world (the server´s classloader). i tried hard several times to find flaws in our code, that may be responsible for that leaking without significant success.
if you face the same trouble, you might take a few minutes to take a look at you logging habits. there are fundamental flaws in both commons-logging and log4j, that might case some trouble.

Taxonomy of class loader problems encountered when using Jakarta Commons Logging (JCL)

Class loading problems encountered when using JCL fall into three main categories:

* Type-I: A java.lang.NoClassDefFoundError thrown when a class is inaccessible from a parent class loader even if the said class is available to a child class loader
* Type-II: Assignment incompatibility of two classes loaded by distinct class loaders, even in case where the two classes are bit-wise identical.
* Type-III: Holding references to a given class loader will prevent the resources loaded by that class loader from being garbage collected.

easiest way to find out if you suffer from this one might be SLF4J:

One of the benefits that SLF4J offers is a reimplementation of the various Commons Logging APIs which will not leak memory. You can continue to program to those APIs. Just deploy your application with jcl-over-slf4j.jar and you'll have the best of both worlds: the ubiquitous JCL API and a non-leaking implementation thereof. This is not a BAD thing.
This is only one use of SLF4J, but it is an important one. I was able to fix an un-unloadable application by replacing ("augmenting") Tomcat's JCL usage with SLF4J.

there is some weakness (or, "strong-ness" in this case ;) in log4j too:

Looks like a logger implementation issue to me

Just my experience with unloading webapps with log4j and Tomcat. Log4j uses Introspector to make some reflection magic during configuration phase (I could be wrong, I fixed some months ago). The problem is that, even if WeakHashMap are used, classes, that are keys in the maps, do not get gc in acceptable time (at least for me). Putting
Introspector.flushCaches();
in my servlet fixed the issue.

taken from here.

I did not try these suggestions yet, but i damn sure will asap.