Eclipse Community Forums: ServerTools (WTP) » WTP 3.2 and Tomcat 7

Home » Language IDEs » ServerTools (WTP) » WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken(The server fails to startup when any Resource or ResourceLink is defined in the webapp's META-INF/context.xml)

Show: Today's Messages :: Show Polls :: Message Navigator

WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546672]

Tue, 13 July 2010 17:37

Nic Baker

Messages: 3
Registered: July 2010

Junior Member

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!

Report message to a moderator

Re: WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546676 is a reply to message #546672]

Tue, 13 July 2010 17:44

Nic Baker

Messages: 3
Registered: July 2010

Junior Member

Oh also - if you take all <Resource> or <ResourceLink> elements out of the webapp project's META-INF/context.xml and place them in the WTP server's context.xml file instead (e.g. Servers/Tomcat v7.0 Server at localhost-config/context.xml in Eclipse's Navigator view) then the server starts up fine and the resource link seems to work, so that seems to me to be more evidence that there's something wrong with how WTP is deploying a Tomcat 7 webapp.

Report message to a moderator

Re: WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546688 is a reply to message #546672]

Tue, 13 July 2010 18:25

Larry Isaacs

Messages: 1354
Registered: July 2009

Senior Member

On 7/13/2010 1:37 PM, Nic Baker wrote:
> 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.getObjectNameKeyPro perties(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(SetNextNam ingRule.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.AbstractXMLDocume ntParser.emptyElement(AbstractXMLDocumentParser.java:180)
>
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.j ava:1339)
>
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(XMLDocumentFragmentSca nnerImpl.java:2747)
>
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(XMLDocumentScannerImpl.java:648)
>
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java: 510)
>
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XML11Configuration.java:807)
>
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(XML11Configuration.java:737)
>
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(X MLParser.java:107)
>
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(AbstractSAXParser.java:1205)
>
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.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(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:26 0)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:41 4)
>
> 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!

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

Report message to a moderator

Re: WTP 3.2 and Tomcat 7 - webapp defined context.xml is broken [message #546720 is a reply to message #546688]

Tue, 13 July 2010 22:38

Nic Baker

Messages: 3
Registered: July 2010

Junior Member

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?

Report message to a moderator

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 12:50

Larry Isaacs

Messages: 1354
Registered: July 2009

Senior Member

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

Report message to a moderator

Previous Topic:	XML Templates not working
Next Topic:	HTML encoding cp1252

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 02:07:46 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter