| WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546672] |
Tue, 13 July 2010 13:37  |
Eclipse User |
|
|
|
I think I found a bug with the latest WTP (3.2) and Tomcat 7 that causes the server to fail to startup if you've defined a webapp-level META-INF/context.xml file that contains a <Resource> or <ResourceLink> element. I think the problem is in WTP because if I wrap up the project in a .war file and launch the server from outside Eclipse/WTP then it works fine.
I did some searching and couldn't find anyone else talking about this so I was hoping to get some confirmation here before filing a bug report.
Simple steps to reproduce:
- Create a Tomcat 7 server runtime environment if you don't already have one and add it to the Servers tab.
- Create a new Dynamic Web Project and make sure its target runtime is the Tomcat 7 server. I also set the dynamic web module version to 3.0 and Configuration to "Default Configuration for Apache Tomcat v7.0" but I don't know if it matters. I left the rest of the options on default.
- Create a context.xml file inside the project's META-INF folder and give it a <Resource> or <ResourceLink>. The simplest is to just link to the UserDatabase global resource provided by Tomcat 7's server.xml. Here's an example context.xml file that should reproduce the problem:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<ResourceLink name="UserDatabase" global="UserDatabase" type="org.apache.catalina.UserDatabase"/>
</Context>
- Add the project to the Tomcat 7 server and launch it via the Servers tab.
Assuming this is a real bug you should see the following stack trace during server startup and the server should fail to start:
Jul 13, 2010 10:30:04 AM org.apache.tomcat.util.digester.Digester endElement
SEVERE: End event threw exception
java.lang.NullPointerException
at org.apache.catalina.core.StandardContext.getObjectNameKeyProperties(StandardContext.java:5551)
at org.apache.catalina.core.StandardContext.setNamingResources(StandardContext.java:1757)
at org.apache.catalina.core.StandardContext.getNamingResources(StandardContext.java:1735)
at org.apache.catalina.startup.SetNextNamingRule.end(SetNextNamingRule.java:99)
at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1058)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1339)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1544)
at org.apache.catalina.startup.Catalina.load(Catalina.java:515)
at org.apache.catalina.startup.Catalina.load(Catalina.java:551)
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.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
If I follow the exact same steps but point it at a Tomcat 6 server then it works fine, and like I said before this problem does not occur if I bypass WTP by deploying directly via a .war file so I think the problem is somewhere in WTP.
Is this a known bug that I missed when digging around in bugzilla and the forums? If not, is anybody else able to reproduce the problem? Thanks for any help!
|
|
|
Home