Tomcat administration

Tomcat is a servlet container, and as such can be used to deploy web applications using Java on the server side.

Tomcat on Gentoo

Currently (19/03/2007), the init scripts on Gentoo are not able to redirect Tomcat's standard output to a file. This is bug 162379 in Gentoo's bugzilla.

This means everything sending stuff to the standard output (for example a console appender in Log4J) won't work. This also means that stack trace logs (caused by exceptions) are not going to be available, since they are outputted to stdout.

Tomcat Classloading

• Tomcat seeems to be picky about classloading. In particular put your JDBC driver (along with Hibernate) in common/lib. I had troubles when it was placed in shared/lib. This seems to happen when you let Tomcat do the pooling.

Tomcat Logging

• If Tomcat finds the log4j.jar on its classpath, it will use log4j as its logging system. And if log4j is not configured at all, *nothing* will be printed anywhere. So if you want to disable log4j logging and use JDK logging, you must delete the log4j.jar, it is not sufficient to delete or remove the log4j.properties file.

• Warning: You need to emerge commons-logging (the base library Tomcat uses for logging) with the log4j USE flag enabled, else it won't be able to use log4j logging!

Tomcat Security

• By default, Tomcat uses a Security Manager on Gentoo. This Security Manager policy is by default, very strict. In particular, it allows JDBC connections but does not allow any kind of write operations on the webapp directory. The security policy configuration file is located at /etc/tomcat-5.5/catalina.policy on Gentoo. Adding for example the following line will make the webapps directory writable by the servlets:

permission java.io.FilePermission "${catalina.home}/webapps/-", "read, write";

The "-" at the end indicates that every file recursively has the permission applied. Don't forget that standard UNIX permissions still apply, so the tomcat user must of course be able to write to the desired directories.

Tomcat Port and Connectors

• The base configuration file for Tomcat is named server.xml. Here you define a server (the port attribute in the server node is used only to shut down Tomcat). Inside this server you can define several connectors. The most basic connector is the HTTP 1.1 connector. It has a port attribute that you can edit in order to change the port.

Session Mechanism

• The cookie set by Tomcat is by default set on the path corresponding to the context path of the web-application. I did not yet find a way to change this (in Jetty you can control every aspect of the session cookie).

Context Path

• Every web application has a context path. To deploy to the root context (the "/" path), currently the only way I have found is to name the WAR file ROOT.war. In Grails I also had to rename the application name to "ROOT".

Java Servlets

• Java servlets can easily access information from GET or POST HTTP requests via the function getParameter("key");. However if you are using a FileUpload servlet, in the POST request the information has to be encoded in a way that makes the standard official Java Servlet API fail. You *must* use the FileUpload API.

• To obtain the current working dir of a servlet, use

getServletContext().getRealPath("/");

Don't use System.getProperty("user.dir") as user.dir is a Java property that has nothing to do with the servlet context.