Hello Yoav, I see a problem with the documentation. It says:
<quote> xerces.jar - The XML parser that is visible by default to Tomcat internal classes and to web applications. This can be overridden, for a particular web application, by including your desired parser in /WEB-INF/lib. </quote> That is very wrong and violates the Sun classloading spec. Tomcat has enforced this since 4.0.2, but things were buggy at that time so Tomcat didn't do a perfect job at ignoring the XML parser. Instead, you'd get ClassCastExceptions and such. I'm pretty sure Xerces is mostly ignored in Tomcat-4.1.12. The XML parser should exist in one of a few places: 1. In the JDK (true with j2sdk1.4.x) 2. Overridden in JAVA_HOME/jre/lib/endorsed 3. Overridden in CATALINA_HOME/common/endorsed 4. Be placed in CATALINA_HOME/common/lib. Note that this will not override existing XML parsers from endorsed directories, but if you are using JDK1.3.x, then it will be used since that JDK version doesn't include an XML parser. The Xerces classes will be loaded either way...unless the full Xerces is in an endorsed directory already. See also: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6374 <quote name="Remy Maucherat"> Yes, I know it doesn't happen with b2. There were other more insidious problems with using a XML parser in a webapp repository (see 6248, and many messages on tomcat-user). It will force the XML base classes (and their subpackages, unfortunately, that's where the bug is) to be loaded from one of the parent shared classloader. I've put a fix already in CVS in both branches (the base XML classes won't be loaded to avoid the classcasts, but all the subpackages will). It is not possible, and is actually forbidden by the servlet spec, to load those classes from the webapp repositories. LATER means that I'd like to implement a better mechanism to fully implement the spec requirements (although it will need some special configuration by the user to define which libraries it has installed). This probably will stay in the HEAD branch, so the resolution of the bug may not be the right one. </quote> I additon, this has some good explanation: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7175 <quote name="Patrick Luby"> I agree with Remy that you should stop trying to override the default XML parser. While you *may* be able to override it when using JDK 1.3, you will absolutely not be able to do it with JDK 1.4 as JDK 1.4 treats the XML parsing classes (also known as "endorsed" classes) as system classes. Hence, once the JVM is started, JDK 1.4 will not all any class loader in the process load alternate XML parsing classes that fall in any package names listed in the following URL: http://java.sun.com/j2se/1.4/docs/guide/standards/index.html The only way around this JDK 1.4 restriction for your webapp only is to create an XML parser with package names that are not listed in the above URL (i.e. a very non-standard parser). There is another way around this restriction. However, it will force all webapps (and the container itself) to use your XML parser. You can put your parser jar files in the common/lib directory (4.0.x) or in the common/endorsed directory (HEAD). </quote> The docs should be changed to match the latest reality. The XML parser *cannot* be overridden by putting it in WEB-INF/lib. Jake Wednesday, December 04, 2002, 8:52:46 AM, you wrote: SY> Hi, SY> Really? You didn't find anything in the docs to even shed a little SY> light? Try: SY> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html SY> (You didn't mention what tomcat version you're using, so I'm assuming SY> 4.1.x). SY> Also see the section in the release notes titled "Tomcat and XML SY> Parsers." SY> Yoav Shapira SY> Millennium ChemInformatics >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, December 04, 2002 9:23 AM >>To: [EMAIL PROTECTED] >>Subject: WebApp Classpath >> >>Hello, >> >>I face a problem using Tomcat with our Web Application regarding Xalan. >>We are using a quite old version of Xalan in our application (it is >>somewhat >>1.x). Now our application refuses to run on Tomcat since Tomcat puts in SY> the >>classpath a Xalan version 2.x. >>Is there a possibility to provide a separate classpath for Tomcat and SY> the >>Web Application? (other Application Servers provide this feature, but I SY> did >>not find anything about it in Tomcat) >> >>Thanks for your help, >>Harald Dietrich >> >>-- >>To unsubscribe, e-mail: <mailto:tomcat-user- >>[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:tomcat-user- >>[EMAIL PROTECTED]> SY> -- SY> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> SY> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Jacob mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
