http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

Současný status quo je ten, že problém se nám 100% odstranit nepodařilo. Po úvodním nadšení jsme zjistili, že problém se podařilo odstranit na testované instalaci, nicméně na jiných přetrvával. Od té doby dopisuji k článku další problémy, na které jsme narazili a které postupně odstraňujeme.

se stejným problémem jsem se potýkal cca před 1,5 rokem ale vy jste byl mnohem preciznější :-). Na problém s JDBC drivery a Springem jsem přišel také, ale externí knhovny jsem příliš nezkoumal. Zajímalo by mě, do jaké míry se Vám podařilo problém odstranit (nebo zmizel úplně?). Pokud si vzpomínám, tak jsem tehdy došel do celkem rozumného stavu, kdy mi Tomcat lehnul až po několika desítkách restartů.

Mám drobnou poznámku, odkaz na RSS kanály úplně dole ve stránce není správný a měl by být nejspíš takový http://blog.novoj.net/feed/

Chápu to tak, že problematická je přítomnost commons-logging v aplikačním serveru. Nebudu zastírat že v tom plavu a víc sem experimentoval.

Nicméně v odkazovaných článcích lze nějaké info nalézt:

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
Not a problem if the Apache Commons code is loaded in your application’s classloader. However, you do have a problem if this code is also present in the classpath of the application server because those classes take precedence. As a result now you have references to classes in your application from the application server’s classloader… a classloader leak!

http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
Except for the brain-dead design of JDBC where jdbc drivers loaded via a custom classloader apparently get stored in a map within java.sql.DriverManager thereby causing cyclic references to that classloader.