Bug 29936 - XML parser loading problems by container
XML parser loading problems by container
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Catalina
5.5.23
PC All
: P3 blocker (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
: 43444 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-07-06 15:18 UTC by peter neville
Modified: 2008-07-30 11:06 UTC (History)
2 users (show)



Attachments
WAR causing problem for container (546.39 KB, application/octet-stream)
2007-09-26 13:54 UTC, Eddy Chan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description peter neville 2004-07-06 15:18:51 UTC
I'm trying to use JSTL 1.1 with this version of tomcat and have both saxon and 
crimson in my web-app.

If we have crimson and saxon in our webapp lib then tomcat tries to use crimson 
as the xml parser when reading the web.xml and compiling the jsp and we get the 
prefix error:

org.apache.jasper.JasperException: <h3>Validation error messages from 
TagLibraryValidator for c</h3><p>null: java.lang.IllegalStateException: can't 
declare any more prefixes in this context</p><h3>Validation error messages from 
TagLibraryValidator for fmt</h3><p>null: java.lang.IllegalStateException: can't 
declare any more prefixes in this context</p>

If we remove crimson, tomcat uses saxon (aelfred parser) and this fails on 
reading the web.xml (javax.xml.parsers.ParserConfigurationException: AElfred 
parser is namespace-aware)

If we remove saxon and crimson then we are okay (defaults to xerces in the 
tomcat endorsed directory?)

It seems to me that tomcat is using the parser in my web-app to read the 
web.xml rather than using xerces from the endorsed directory.  

The same web-app runs without problems in version 5.0.16.  

Tomcat seems to be using the service provider mechanism in 5.0.25 as I have 
property files in C:\Java\jakarta-tomcat-5.0.25
\work\Catalina\localhost\diabetes\loader\META-INF\services (can't find any 
documents on this).

If I'm using more than one parser won't this cause problems as tomcat is 
setting only one parser and xslt processor here?

Any comments are gratefully received.

Thanks,
Peter Neville
Comment 1 peter neville 2004-07-06 15:21:39 UTC
BTW: Java SDK is version 1.4.2_01
Comment 2 Remy Maucherat 2004-07-06 15:52:31 UTC
I am afraid if you want this resolved, you'll have to investigate this further.
One thing which really hurts your report is the fact that this would be a
classloader issue, and yet there is no relevant functional changes in the
classloader since 5.0.16.
Comment 3 Tim Funk 2004-07-06 16:02:18 UTC
Are you sure you haven't duplicated the tagdef in the JSP multiple times?

For example - this would cause an error:
<%@ taglib uri="http://java.sun.com/jstl/core/c.tld" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jstl/core/c.tld" prefix="c" %>

Or this:
<%@ taglib uri="http://java.sun.com/jstl/core/c.tld" prefix="c" %>
<%@include page="foo.jsp"%> 

where foo.jsp also has:
<%@ taglib uri="http://java.sun.com/jstl/core/c.tld" prefix="c" %>
Comment 4 peter neville 2004-07-07 07:57:06 UTC
Remy: You mention that there hasn;t been any classloader chnages since 5.0.16, 
but to the best of my knowledge 5.0.16 did not store service provider details 
in the apache work/catalina/localhost/webapp/loader sub-directories.
Are there any explanations on this available?

Tim:

The taglibs are declared as:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

So not multiple declarations - there ins aninclude but this doesn't use taglibs.

The problem is instantly resolved by removing saxon and crimson from the web-
app lib.


Thanks for your help so far...
Comment 5 peter neville 2004-07-07 08:20:53 UTC
Also, I must set my web.xml for the web-app to :
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd"
    version="2.4">

instead of :

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>


Otherwise tomcat gives errors when compiling the jsp indicating that it can't 
find bean properties etc.
Comment 6 Remy Maucherat 2004-07-07 14:49:47 UTC
If you don't know what 5.0.16 has and what it does not have, I think you need to
check the CVS history. I really cannot see anything I'd like to test in this bug
report (except the usual: we don't support replacing the XML provider, except
using the JVM provided mechanism).
Comment 7 Eliot Stock 2004-07-13 17:19:49 UTC
for what it's worth I'm seeing the same thing with:

tomcat 5.0.25
jstl 1.1
j2dsk 1.4.2_05
linux

for a web app that has crimson in the WEB-INF/lib. Removing the JAR that
contains crimson fixes it. It's surprising to me that tomcat is using the parser
it finds in the web app for web.xml and JSP compilation - not what I'd expect
and will probably trip other people up the same way.
Comment 8 Eddy Chan 2007-06-07 12:15:01 UTC
This issue is also prevalent in 5.5.x.  To reproduce, do the following:

1) Remove all stock webapps that come with the standard installation.  This
includes the ones in server/webapps.  Remember to remove the configurations in
conf/Catalina.
2) Add a webapp that has a saxon parser located in WEB-INF/lib.  For instance,
one from sourceforge.
3) Start Tomcat.  You should a stack trace similar to this:

Jun 7, 2007 11:33:29 AM org.apache.commons.digester.Digester getParser
SEVERE: Digester.getParser: 
javax.xml.parsers.ParserConfigurationException: AElfred parser is namespace-aware
	at
com.icl.saxon.aelfred.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:37)
	at org.apache.commons.digester.Digester.getParser(Digester.java:686)
	at org.apache.commons.digester.Digester.getXMLReader(Digester.java:902)
	at org.apache.commons.digester.Digester.parse(Digester.java:1548)
	at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:515)
	at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:623)
	at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
	at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277)
	at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
	at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:625)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:431)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
	at org.apache.catalina.core.StandardService.start(StandardService.java:480)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
Jun 7, 2007 11:33:29 AM org.apache.catalina.startup.ContextConfig defaultConfig
SEVERE: Parse error in default web.xml
java.lang.NullPointerException
	at org.apache.commons.digester.Digester.getXMLReader(Digester.java:902)
	at org.apache.commons.digester.Digester.parse(Digester.java:1548)
	at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:515)
	at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:623)
	at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
	at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277)
	at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
	at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:625)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:431)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
	at org.apache.catalina.core.StandardService.start(StandardService.java:480)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)

I believe the issue here is that when the Digester to parse web.xml is set in
ContextConfig, the path to WEB-INF/lib is established for the WebappClassloader.
 When the SAXParserFactory is created with newInstance() within the call to
Digester.getParser(), the rules dictate that it will search thirdmost for a file
META-INF/services/javax.xml.parsers.SAXParserFactory in jars available, and it
will find it in saxon.jar, prior to defaulting to a platform default parser. 
This webapp parser is now used for parsing the web.xml file, but since this task
is the container's responsibility, it should not be used.  As a note, this
particular parser needs to be namespace-aware and the setting of it being not
namespace-aware throws this exception.

A possible solution is to load the (default) parser into the Digester prior to
having it being loaded by the WebappClassloader.  Since this appears to be
one-time settable, it will use this parser regardless of what the webapp has.
Comment 9 Ryan Sweet 2007-08-02 11:08:22 UTC
Eddy, which particular sourceforge webapp did you use to test this?
Comment 10 Eddy Chan 2007-08-07 14:10:59 UTC
The webapp was one of my own, but you just need a bare one, I believe.  It
contained a saxon parser from Sourceforge, which overrides the default parser.
Comment 11 Mark Thomas 2007-09-03 17:50:13 UTC
This works for me, at least I can't reproduce by following the steps provided
here, with the latest source from svn.

Please test this with the latest 5.5.x release. If you still see the issue,
please provide the simplest possible WAR that reproduces the issue on a clean
Tomcat install along with any additional configuration steps that may be required.
Comment 12 Eddy Chan 2007-09-26 13:54:44 UTC
Created attachment 20889 [details]
WAR causing problem for container
Comment 13 Eddy Chan 2007-09-26 13:56:44 UTC
I've attached a small problematic WAR that just contains a blank web.xml along
with a saxon.jar in the WEB-INF/lib.  Remember that you need to remove ALL the
apps that come with Tomcat (rm -fr webapps/*) as well as the configs (rm -fr
conf/Catalina).
Comment 14 John Kew 2007-10-02 14:52:12 UTC
I can replicate this issue with the provided war on 5.5.x. It seems odd that
this only occurs with the conf/Catalina and other webapps missing.
Comment 15 Mark Thomas 2008-04-20 13:46:01 UTC
The root cause of this issue is the ContextConfig class creating the parser for web.xml whilst it is using the webapp's classloader. This causes a problem if the app being processed includes an xml parser.

I have committed a fix to trunk and will propose it for 6.0.x and 5.5.x.
Comment 16 Mark Thomas 2008-04-25 12:18:14 UTC
*** Bug 43444 has been marked as a duplicate of this bug. ***
Comment 17 Mark Thomas 2008-05-01 10:43:29 UTC
This has been committed to 6.0.x and will be in 6.0.17 onwards.
Comment 18 Mark Thomas 2008-07-30 11:06:36 UTC
This has been fixed in 5.5.x and will be included in 5.5.27 onwards.