Hello Màris, That particular quote that you mention below (from the Tomcat docs) needs to be rewritten. You can't override endorsed packages from within the WEB-INF/lib. It violates the Sun classloading spec and ever since Tomcat-4.0.2, Tomcat enforces this.
For evidence of this, see... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6248 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6476 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> As far as getting Tomcat to use the appropriate parser, I'm not sure how to help you there. You'll just have to test a number of things out. Jake Wednesday, January 29, 2003, 9:41:54 AM, you wrote: MO> hello all MO> I want to use SAXON XML parser in my WEB app. I put saxon.jar and saxon-jdom.jar in web-inf/lib MO> of my web app. Now Tomcat doesnt work at all, it throws at startup: MO> [ERROR] Digester - -Digester.getParser: <javax.xml.parsers.ParserConfigurationException: MO> AElfred parser is non-validating> MO> javax.xml.parsers.ParserConfigurationException: AElfred parser is non-validating MO> It seems that Tomcat tries to SAXON as default XML parser. MO> I tried to move Xerces and jaxp jar's from common/endorsed to /server/lib, it didnt work, ClassCastException was thrown, it seems because of duplicated classes loaded by saxon.jar and MO> xmlParserAPIs.jar. (classes are different but with the same name ) MO> I was very upset, because I have read in Tomcat docs: MO> "Common - This class loader contains additional classes that are made visible to both Tomcat internal classes and to all web applications. MO> 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 MO> parser in /WEB-INF/lib. " MO> I use Tomcat 4.1.18 and jdk 1.3.1. (NOT LE) MO> thanx in advance MO> Maris Orbidans MO> --------------------------------------------------------------------- MO> To unsubscribe, e-mail: [EMAIL PROTECTED] MO> For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards, Jacob mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
