Když už nastane leak a classloader se neuvolní (což je skoro vždy), samozřejmě pomůže, když v tomto classloaderu je tříd co nejméně (tím se zmenší velikost memory leaku).

Pak je ještě řešení všechno naopak nahrát do /WEB-INF/lib. Ale stejně knihovny z JDK (např. JDBC DriverManager) jsou v původním classpath.

Takže IMHO správným řešením je, aby tomcat uvolnil všechny co je v JDK a jary mít ve /WEB-INF/lib. Pokud ovšem přidáme do globální classpath něco co tomcat nezná a nemůže tak uvolnit, máme opět problémy. Proto mají některé wary různé uvolňovače.

Čím více nad tím přemýšlím, tím více se mi zdá, že způsob jakým se v současné době izolují aplikace v kontejneru není zrovna nejlepší (a těmito slovy tedy potvrzuji tvrzení Arnošta, že se jedná o chybu architektury).

Mám jenom několik dodatků.

1. Co se týká JBosse, tak tento problém existuje také. Takže není pravda, že problémy s integrovaným tomcatem nenastávají. (JBoss 4.0.3 SP1)
2. Někde jsem četl, že problém PermGen způsobují statické instance tříd, které jsou používány ve webových aplikacích – toto ber jenom jako naznak dalšího možného zkoumání. Bylo doporučeno, co nejvíce knihoven nahrát do sdíleného knihovního adresáře tomcata – co nejméně do /WEB-INF/lib.

Snad Ti to nějak pomůže.