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
BTW: Java SDK is version 1.4.2_01
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.
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" %>
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...
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.
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).
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.
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.
Eddy, which particular sourceforge webapp did you use to test this?
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.
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.
Created attachment 20889 [details] WAR causing problem for container
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).
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.
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.
*** Bug 43444 has been marked as a duplicate of this bug. ***
This has been committed to 6.0.x and will be in 6.0.17 onwards.
This has been fixed in 5.5.x and will be included in 5.5.27 onwards.