tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <>
Subject Re: HTTP Status 500 - Server Internal Error (continued!)
Date Sun, 19 Dec 2010 22:12:31 GMT
McGibbney, Lewis John schrieb am 19.12.2010 um 18:56 (+0000):
> I managed to get over the parser issue by
> following your suggestions.


> I am now encountering errors with the class
> org/apache/common/logging/LogFactory when I try
> to launch webapp on Tomcat.

Commons Logging is frequently encountered as a
dependency in JARs you might want to include with
your app - and unfortunately not always in
compatible versions.

> Reading my Tomcat output logs I notice the
> following code in the final few lines before the
> console window closes.
> SEVERE: A web application appears to have
> started a thread named [Thread-4] but has failed
> to stop it. This is very likely to create a
> memory leak.

Newer Tomcats detect errors that previously went
by unnoticed.

I'm not sure the thread Tomcat points out wasn't
stopped is related to Commons Logging. Could it be
that you created the thread in your app?

> Having delved into the world of commons logging
> I am interested to hear whether the correct
> solution to solve a memory leak when deploying/
> undeploying a webapp is to include a class which
> implements ServletContextListener(according to
> commons wiki FAQ's).

This one? This is about references held by a class
in the container classloader to a class in the
webapp classloader, which prevents *all* of the
webapp classes from being unloaded on undeploy.

The problem is not related to Tomcat's complaint
about the thread that wasn't stopped.

> I am concerned that in beating the parser
> problem I have opened a can of worms.

Hmm, the missing Apache Xerces and the dangling
thread are unlikely to be related.

Michael Ludwig

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message