McGibbney, Lewis John schrieb am 19.12.2010 um 18:56 (+0000): > > I managed to get over the parser issue by > following your suggestions.
Fine! > 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). http://wiki.apache.org/commons/Logging/UndeployMemoryLeak 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
