| Summary: | class not find for:org/w3c/dom/range/Range | ||
|---|---|---|---|
| Product: | Tomcat 4 | Reporter: | Kenny Yang <kenny.j.yang> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bill, bk, brett.knights, chung_po_loi, dev, gheorghe, ivan, javaXpert, jrspm, jserna, lei, mstam, ravimadhu, sascha.weinreuter, vijay_phadke |
| Priority: | P3 | ||
| Version: | 4.0.2 Final | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | other | ||
|
Description
Kenny Yang
2002-02-11 19:52:09 UTC
Please see the answer I posted on tomcat-user: <quote> 4.0.2 now tries to implement the requirement of preventing to load a shared library from the webapp loader. Unfortunately, the feature is not smart enough at the moment, and will filter out any DOM or SAX related class. To fix it, move the DOM classes in 'lib' or 'common/lib'. </quote> I'll try to address this soon, by refactoring the triggers, and allowing the user to configure them (which will be the best implementation I can think of of what the spec requires). I can confirm that this is happening. However, it is not happening in 4.0.2- b2, only in 4.0.2 Final. I changed the version to reflect that. I also figure that the Component is Catalina, so I made that change. I work on a project called Barracuda hosted at http://barracuda.enhydra.org/. It uses xmlc which contains XML and DOM classes that are pretty dated. For this reason, we always put the xmlc.jar in the WEB-INF/lib directory. This works great in Tomcat 3.3 and 4.xx up to 4.0.2-b2. In 4.0.2 Final, we are now seeing the reported error. I have also seen a number of error reports from others: http://www.apachelabs.org/tomcat-user/200202.mbox/% 3c24946BD18054D4119BE200D0B73E87778D5F50@BOROMIR%3e Here's one reporting Cocoon breaking in 4.0.2: http://www.apachelabs.org/tomcat-user/200202.mbox/%3c009301c1b3e9$4f6e5ff0 $6501a8c0@apache.org%3e If this is a "feature", I can't belieive that a feature that didn't exist in 4.0.2-b2 was released without another beta. Please fix this sooner than "Later"! Jake 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. This problem has been fixed in both branches (4.0 and HEAD). The classloader will now match the exact package name. *** Bug 6449 has been marked as a duplicate of this bug. *** *** Bug 6556 has been marked as a duplicate of this bug. *** *** Bug 6656 has been marked as a duplicate of this bug. *** The method WebappClassLoader.validate blocks out the loading of any classes belonging to javax.xml.* as well as a few other XML related packages in the webapps/lib and webapp/classes directory. This makes it impossible for a specific web application to use its own XML classes. Also, it makes it impossible for applications to do XSL transformation using javax.xml.transform.* classes. (We are using xalan for this). The work around would be putting the jar files in common/lib, but this is not ideal and prevents each webapp from having its own XML handling classes. Please try to read the previous comments for this bug report. Thanks. *** Bug 6663 has been marked as a duplicate of this bug. *** Just tried Catalina 4.0.3 with Cocoon CVS. If Xerces/Xalan/xml-apis JAR files are copied under common/lib, the result is ClassCastException: java.lang.ClassCastException: org.apache.xerces.parsers.StandardParserConfiguration at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(Unknown Source) at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(Unknown Source) at org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.generateCode (AbstractMarkupLanguage.java:377) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateRes ource(ProgramGeneratorImpl.java:369) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createResou rce(ProgramGeneratorImpl.java:331) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load (ProgramGeneratorImpl.java:294) at org.apache.cocoon.sitemap.Handler.run(Handler.java:270) at java.lang.Thread.run(Thread.java:484) And messages in the console: SAX2 driver class org.apache.xerces.parsers.SAXParser does not implement XMLReader SAX2 driver class org.apache.xerces.parsers.SAXParser does not implement XMLReader This seems as ClassLoader issues to me. If mentioned files are removed from the WEB-INF of the Cocoon webapp, this prevents Cocoon from compiling its sitemap (Java compiler requires these files): org.apache.cocoon.ProcessingException: Language Exception: org.apache.cocoon.components.language.LanguageException: Error compiling sitemap_xmap: Line 5081, column 49: error while loading class org.xml.sax.ContentHandler: java.io.IOException: file org\xml\sax\ContentHandler.class not found Line 0, column 0: 1 error Work around ClassLoading issues for Cocoon under Tomcat 4.0.3:
1. Move xalan/xerces/xml-apis/batik from cocoon/WEB-INF/lib to the
tomcat/common/lib
2. Add extra-classpath parameter to the cocoon/WEB-INF/web.xml:
<init-param>
<param-name>extra-classpath</param-name>
<param-value>C:\Apache\jakarta-tomcat-4.0.3\common\lib\xalan-
2.3.1.jar;C:\Apache\jakarta-tomcat-4.0.3\common\lib\xercesImpl-
2.0.0.jar;C:\Apache\jakarta-tomcat-4.0.3\common\lib\xml-
apis.jar;C:\Apache\jakarta-tomcat-4.0.3\common\lib\batik-libs-1.1.1.jar</param-
value>
</init-param>
Why did you reopen this bug ? It isn't the same issue at all. Please file a new bug. Also, TC 4.0.3 is 100% identical to 4.0.2 for Cocoon. *** Bug 6948 has been marked as a duplicate of this bug. *** Kenny, The fix (as far as I can tell) is in 4.04b1. *** Bug 6977 has been marked as a duplicate of this bug. *** *** Bug 6640 has been marked as a duplicate of this bug. *** *** Bug 7717 has been marked as a duplicate of this bug. *** *** Bug 8020 has been marked as a duplicate of this bug. *** Please provide details on the proper work arounds for Tomcat 4.0.3 Final and Cocoon 2.0.2 in the Cocoon Installation Document. This is an anoying little bug and I can't seem to get around it due to conflicting installation instructions. *** Bug 8622 has been marked as a duplicate of this bug. *** *** Bug 9360 has been marked as a duplicate of this bug. *** *** Bug 9371 has been marked as a duplicate of this bug. *** Dear Remy, By reading these comments, it seems that the problem is fixed. But I still encounter exactly the same problem in tomcat 4.03. Would you mind to tell me what to do so that I could load the class "org.w3c.dom.range.Range"? Thanks. 4.0.4b3 works ootb. |