There appears to be an issue when attempting to use a JNDI datasource when defining a ROOT context. So with the simple server.xml: <Server port="8005" shutdown="SHUTDOWN"> <GlobalNamingResources> <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <Service name="Catalina"> <!-- HTTP connector --> <Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml" /> <!-- HTTPS connector --> <Connector port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> <!-- AJP 1.3 connector (needed?) --> <Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" /> <Engine name="Catalina" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> <Host name='localhost' appBase='webapps' unpackWARs='false' autoDeploy='true' deployOnStartup='true' xmlValidation='false' xmlNamespaceAware='false'> <Context path='/' docBase='ROOT.war' crossContext='true'> <Resource name='jdbc/myDB' auth='Container' type='javax.sql.DataSource' driverClassName='org.postgresql.Driver' url='jdbc:postgresql://localhost:5432/myDB' username='db-user' password='db-passwd' /> </Context> </Host> </Engine> </Service> </Server> When you do: Context ctx = new InitialContext(); DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myDB"); Connection conn = ds.getConnection(); The following error gets throw: org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create JDBC driver of class '' for connect URL 'null' at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:780) at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) If you move the resource definition to <GlobalNamingResources> and do a resource link you get the same error. But if you change any of the following, it works fine: - Move the resource definition (or link if defined globally) to $CATALINA_HOME/conf/context.xml and remove it from the context entry in server.xml - Move the context defintion out of server.xml completely to $CATALINA_HOME/conf/Catalina/localhost/ROOT.xml - Move the context defintion out of server.xml completely to <webapp>/META-INF/context.xml - Keep the context entry and resource definition in server.xml but change the context path to something besides '/' This indicates that web applications mounted on the root context are treated differently from other web applications. I think it should be consistent.
A discussion of the topic from TSS: http://theserverside.com/discussions/thread.tss?thread_id=25459#137873
The cause of the problem might be described in bug #30117 that notices that resource parameters are ignored under the root context.
The right path to be used in server.xml is "", not "/". What you did would just create another webapp which would never be accessed, while your webapp would be deployed by the auto deployer, without your parameters. We used to have an example in server.xml for this special case (<Context path="" docBase="ROOT" debug="0"/>), but it's removed as we recommend not using server.xml for declaring contexts. Try to avoid using Context elements in server.xml except for webapps which are outside of the Host appBase. Instead, as you mention, use $CATALINA_HOME/conf/Catalina/localhost/ROOT.xml or whatever_your_war_is.war/META-INF/context.xml, but don't use either docBase or path (which would be ignored anyway) on your Context element. Note: The AJP connector is not needed, if you don't use it. (makes sense, I suppose)
Thanks for the heads up.
*** Bug 38307 has been marked as a duplicate of this bug. ***