If you were a luck systems administrator who followed the instructions for a Tomcat container installation using the EAR-WAR install when setting up Atlassian JIRA, then you may have been privileged to see the following error message in your log files:
2009-12-06 22:56:25,762 main WARN [core.entity.transaction.JNDIFactory] [ConnectionFactory.getConnection]
Failed to find DataSource named java:comp/env/jdbc/JiraDS in JNDI server with name default.
Trying normal database. javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
If you’d like the solution on how to get rid of this error, please read on.
Many EAR-WAR installs are lucky to not have this error, because they’re likely installing their instance of JIRA at a URL like http://jira.example.com/. In my case(s), I always buy the suite of Atlassian products (JIRA, Confluence, Fisheye, Crowd, Bamboo) and would like to reference them through a single proxy instance (e.g. http://intranet.example.com//). I put each instance in a separate virtual machine and use mod_jk through an Apache front-end proxy to accomplish this, this allowing me to have a single Tomcat container per application.
The problem with this was that the referenced JDBC path is not in-fact java:comp/env/jdbc/JiraDS, but rather java:comp/env/jira/jdbc/JiraDS. This is due to how Tomcat handles contexts, and by placing our resource inside a nested context (re: Context path="/jira"), we have in effect changed what tomcat references that context as. So, one could choose to update the JDBC path, but I chose a different route - placing the resources in a global contexts.
By moving the Resource definitions to /var/lib/tomcat-6/conf/context.xml: