Hi I managed to get over the parser issue by following your suggestions. Just as I thought things were gradually getting better I am now encountering errors with the class org/apache/common/logging/LogFactory when I try to launch webapp on Tomcat. 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. 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 is the last thing that I would have expected when experimenting with a new plugin for my webapp and I am concerned that in beating the parser problem I have opened a can of worms. Does anyone have any comments here please. Thanks Lewis ________________________________________ From: Michael Ludwig [mil...@gmx.de] Sent: 19 December 2010 12:35 To: users@tomcat.apache.org Subject: Re: HTTP Status 500 - Server Internal Error McGibbney, Lewis John schrieb am 18.12.2010 um 21:20 (+0000): > > I understand this now, my initial understanding > was that Tomcat was distributed with a version > of xerces (or some other) parser implementation Tomcat isn't, but the Sun JRE is shipping a forked and modified Apache Xerces. It has acquired a reputation for bugginess, though, which is why many people prefer to use Apache Xerces (formerly known as IBM XML4J, donated in 1999). > I am trying to get to the bottom of what > org.apache.xerces.util.XMLChar is and why it > is causing the exceptions and errors when I > lanuch the webapp. Something's compiled against this class and complains that it cannot be loaded. You need to make Apache Xerces available to the webapp in question. This can be achieved by putting the relevant JAR(s) in WEB-INF/lib. In the case of Xerces, however, it is preferable to put the JAR(s) into %CATALINA_HOME%\endorsed (which may not exist but may be created) so they will be available to all of Tomcat and outmatch the Sun fork shipping with the JRE. > Can you expand on your final statement to > provide more detail please, I am unfamilar > with this configuration. Take a look at the setclasspath and catalina shell scripts in %CATALINA_HOME%\bin. Search them for "endorsed" and read up on the Java Endorsed Standards Override Mechanism: http://download.oracle.com/javase/6/docs/technotes/guides/standards/index.html -- Michael Ludwig --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Email has been scanned for viruses by Altman Technologies' email management service - www.altman.co.uk/emailsystems Glasgow Caledonian University is a registered Scottish charity, number SC021474 Winner: Times Higher Education’s Widening Participation Initiative of the Year 2009 and Herald Society’s Education Initiative of the Year 2009 http://www.gcu.ac.uk/newsevents/news/bycategory/theuniversity/1/name,6219,en.html
