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:
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.
My jira.xml file (used to) look as follows:
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:
Leaving my actual JIRA configuration instance at /var/lib/tomcat-6/conf/Catalina/jira.example.com/jira.xml to become:
This didn’t require me to change any of Atlassian JIRA’s configuration files, and the error disappeared.