Update to Tomcat 5.5

Last night I updated the underlying server for this web site from Tomcat5 to Tomcat5.5

I wanted to make use of the ability of Tomcat5.5 to take the context.xml file from within the .war file of the application and automatically use it. This means that I can keep the development of this project together (under the git version control system) much more easily than trying to separately edit a configuration file for each new application added (or updated).

Last night I updated the underlying server for this web site from Tomcat5 to Tomcat5.5

I wanted to make use of the ability of Tomcat5.5 to take the context.xml file from within the .war file of the application and automatically use it. This means that I can keep the development of this project together (under the git version control system) much more easily than trying to separately edit a configuration file for each new application added (or updated).

I had two rather subtle problems that are worth describing here, one to do with a change in the way Postgres works, and the second because the documentation for Tomcat don’t really explain fully what happens and there is a bug in the Debian (Etch at the time of writing – the unstable version has the bug fixed) distribution.

Firstly the Postgres problem. I had previously created a database user called tomcat4 and another called apache2 to access the user database. tomcat4 was for the java application and apache2 was for the security access for this site managed by apache2. Anyway, I tried to change these to tomcat and apache respectively so that I didn’t have to change these parts of the application just because I upgraded version. So I created new roles (users) in Postgres, only to find that the whole process of logging in stopped working. I eventually discoverd that Postgres 8.1 had introduced the concept of users who could login and that if I was not careful the default was no login (its more complicated that that, but if it applies to you you can read the documentation). Once I changed these values this part was working again.

The second problem is exactly how tomcat dealts with the context.xml file it finds. It actually physically copies the context.xml file from the .war file to $CATALINAHOME/conf/$ENGINENAME/$HOSTNAME/$APPNAME.xml. Unfortunately the Debian distribution runs tomcat under the tomcat55 username but makes the $CATALINAHOME/conf directory owned by root and with 755 access rights. So the file permissions was wrong, the context was not set up, and the resources to access the database not created. As a result as soon as the application tried to access the database it failed with a jdbc failure.

Any it is working now – I hope. So ready for the next step (my bug reporting section called iTrac).

Author: Alan

I am Alan Chandler.

Leave a Reply

Your email address will not be published. Required fields are marked *