Bug 6374

Summary: class not find for:org/w3c/dom/range/Range
Product: Tomcat 4 Reporter: Kenny Yang <kenny.j.yang>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: blocker CC: bill, bk, brett.knights, chung_po_loi, dev, gheorghe, hoju, ivan, javaXpert, 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
Hi,
 I downloaded the 4.02 and installed on my machine(Windows 2000) and I copied 
an existing web-app(JSP application) from 4.0 directory. When I tried to run 
this JSP application, I got following exception: 
I checked the xerces.jar in the common path and find there is 
only:/org/w3c/dom/ranges package.
 Hope you can fix this problem soon.

Kenny Yang


type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) 
that prevented it from fulfilling this request.

exception 

javax.servlet.ServletException: Servlet.init() for servlet jsp threw exception
	at org.apache.catalina.core.StandardWrapper.loadServlet
(StandardWrapper.java:935)
	at org.apache.catalina.core.StandardWrapper.allocate
(StandardWrapper.java:653)
	at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2343)
	at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:468)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1012)
	at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
	at java.lang.Thread.run(Thread.java:484)


root cause 

java.lang.NoClassDefFoundError: org/w3c/dom/range/Range
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:120)
	at org.apache.xerces.parsers.DOMParser.setDocumentClassName
(DOMParser.java:501)
	at org.apache.xerces.parsers.DOMParser.(DOMParser.java:232)
	at org.apache.xerces.jaxp.DocumentBuilderImpl.
(DocumentBuilderImpl.java:48)
	at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder
(DocumentBuilderFactoryImpl.java:37)
	at org.apache.jasper.parser.ParserUtils.parseXMLDocument
(ParserUtils.java:197)
	at org.apache.jasper.compiler.TldLocationsCache.processWebDotXml
(TldLocationsCache.java:165)
	at org.apache.jasper.compiler.TldLocationsCache.
(TldLocationsCache.java:138)
	at org.apache.jasper.EmbededServletOptions.
(EmbededServletOptions.java:345)
	at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:266)
	at org.apache.catalina.core.StandardWrapper.loadServlet
(StandardWrapper.java:916)
	at org.apache.catalina.core.StandardWrapper.allocate
(StandardWrapper.java:653)
	at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:190)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2343)
	at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:468)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:174)
	at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
	at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
	at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1012)
	at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
	at java.lang.Thread.run(Thread.java:484)
Comment 1 Remy Maucherat 2002-02-12 23:54:18 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).
Comment 2 Jacob Kjome 2002-02-13 00:07:52 UTC
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
Comment 3 Remy Maucherat 2002-02-13 01:44:10 UTC
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.
Comment 4 Remy Maucherat 2002-02-13 01:51:01 UTC
This problem has been fixed in both branches (4.0 and HEAD). The classloader
will now match the exact package name.
Comment 5 Remy Maucherat 2002-02-14 06:06:34 UTC
*** Bug 6449 has been marked as a duplicate of this bug. ***
Comment 6 Remy Maucherat 2002-02-19 17:42:12 UTC
*** Bug 6556 has been marked as a duplicate of this bug. ***
Comment 7 Remy Maucherat 2002-02-25 16:53:59 UTC
*** Bug 6656 has been marked as a duplicate of this bug. ***
Comment 8 Lei Zhu 2002-02-25 17:05:28 UTC
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.

Comment 9 Remy Maucherat 2002-02-25 17:07:49 UTC
Please try to read the previous comments for this bug report. Thanks.
Comment 10 Remy Maucherat 2002-02-26 00:36:21 UTC
*** Bug 6663 has been marked as a duplicate of this bug. ***
Comment 11 Vadim Gritsenko 2002-03-02 16:57:33 UTC
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

Comment 12 Vadim Gritsenko 2002-03-02 18:25:59 UTC
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>
Comment 13 Remy Maucherat 2002-03-02 18:54:12 UTC
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.
Comment 14 Remy Maucherat 2002-03-07 08:19:09 UTC
*** Bug 6948 has been marked as a duplicate of this bug. ***
Comment 15 brett.knights 2002-03-07 14:22:31 UTC
Kenny,
The fix (as far as I can tell) is in 4.04b1.
Comment 16 Remy Maucherat 2002-03-08 16:33:31 UTC
*** Bug 6977 has been marked as a duplicate of this bug. ***
Comment 17 Remy Maucherat 2002-03-15 06:41:54 UTC
*** Bug 6640 has been marked as a duplicate of this bug. ***
Comment 18 Remy Maucherat 2002-04-03 14:26:33 UTC
*** Bug 7717 has been marked as a duplicate of this bug. ***
Comment 19 Remy Maucherat 2002-04-12 15:00:16 UTC
*** Bug 8020 has been marked as a duplicate of this bug. ***
Comment 20 Brian P Michael 2002-04-19 20:54:22 UTC
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.

Comment 21 Remy Maucherat 2002-04-29 15:14:33 UTC
*** Bug 8622 has been marked as a duplicate of this bug. ***
Comment 22 Remy Maucherat 2002-05-24 00:23:28 UTC
*** Bug 9360 has been marked as a duplicate of this bug. ***
Comment 23 Remy Maucherat 2002-05-24 06:34:19 UTC
*** Bug 9371 has been marked as a duplicate of this bug. ***
Comment 24 Paul Chung 2002-05-24 06:48:13 UTC
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.
Comment 25 John Morrison 2002-05-24 07:48:41 UTC
4.0.4b3 works ootb.