| 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!
|
|
|
|
|
|
| Re: WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546852 is a reply to message #546720] |
Wed, 14 July 2010 08:50  |
| Eclipse User |
|
|
|
On 7/13/2010 6:38 PM, Nic Baker wrote:
> Larry Isaacs wrote on Tue, 13 July 2010 14:25
>> It appears the startup process has changed in Tomcat 7 such that the
>> <ResourceLink>, when part of a <context> in server.xml, gets processed
>> before the server is sufficiently initialized. If you open the server
>> editor in Eclipse and enable the "Publish module contexts to separate
>> XML files" option, I believe you will avoid this issue. I'll see about
>> force enabling this option for Tomcat 7 servers in WTP 3.2.1.
>>
>> Cheers,
>> Larry
>
>
> Yep, that workaround fixed the problem. Thanks for the quick and helpful
> reply!
>
> Out of curiosity, what drawbacks (if any) are there to having the
> "Public module contexts to separate XML files" option checked? Will it
> make the server startup more slowly, or are there other gotchas I should
> be aware of now that I have this option turned on?
It is probably more "normal" to have it enabled for Tomcat 5.5 and 6.0,
and as you have discovered, kind of required for Tomcat 7. It hasn't
been enabled by default mainly because I'm trying to avoid having the
support for the various versions of Tomcat diverge more than necessary.
Now that it's needed by Tomcat 7, it is worth the effort to enable it
by default for appropriate versions. I'll try to get this into WTP 3.2.2.
Cheers,
Larry
|
|
|
Powered by
FUDForum. Page generated in 0.05739 seconds
Home