Tomcat: forgotten features

Wednesday, March 19, 2014

Most Java developers are familiar with Tomcat. It is a mature, lightweight and easy to use web server for Java web applications. But it's still surprising how few people are aware and use some of the basic features/concepts of this application. This blogpost describes some of the features Tomcat users should be familiar with and use them as much as possible.

Make use of base directories
If you have, for example, five web applications you want to expose to your users, there are 3 kind of setups you can use for this:
  1. Set up a Tomcat server and deploy all five web applications on this instance.
  2. Set up five Tomcat servers, one for each web application. Most business applications will use this kind of setup.
  3. Install one Tomcat server and make use of base directories.
The first kind of setup is only interesting for small applications which don't put a lot of load on a server. Most developers will install different Tomcat servers, and use each installation for only one web application. The big advantage of this kind of setup is that you can tweak the amount of resources each server/application is allowed to use. If, for some reason, a Tomcat server goes down, the other servers will remain running. The big disadvantage of this kind of setup is the installation and maintenance of the servers. Configurations sometimes have to be kept in sync, upgrading of database drivers or connection pools have to be done on all servers, … making use of base directories can resolve most of these problems.
When you want to use base directories, there is only one installation of Tomcat, which is referred to as Tomcat home. This installation contains mainly the executables and shared libraries of Tomcat. If you want to use connection pools with JNDI, database drivers are also installed in these directories.
For each web application you create a Tomcat base directory. This directory contains the configuration files (like server.xml and context.xml) that are specifically adapted to the needs of your web applications. The base directory also contains the log, work, temp and webapps directories for your application.
Now what is the big advantages of this setup?
  • There is only one installation of Tomcat.
    • All applications use the same version of Tomcat and Java.
    • Upgrades of Tomcat can easily be performed (less maintenance costs).
    • Less disk usage, since all libraries are shared and located at one place.
  • Each web application can have it's own configuration and resource management.
  • Setup of a new instance for a new application is easier.
  • Each application runs in it's own instance, so the individual applications can have a bigger uptime.
Environment specific settings
Most companies have different environments for development, quality assurance and production. Your application should not contain configurations of environment specific settings like database servers, file locations, external hosts, etc. These kind of configurations should be kept outside of your web application (war). The context.xml file can help you with this.
The context.xml file is a file that is located in the home or base directory of your Tomcat. It is not overridden by a new deployment of your application, so once it is there, it stays there with the configured values. Now you can place your environment specific settings in this XML file. You can place string values in it, configure your database with JNDI, …
If your application uses a lot of environment specific settings, you might want to use your own kind of configuration files (XML, JSON or just plain text files). In this case you can put the location of these configuration files in the context.xml file.
Never run your Tomcat server as a root user. Running Tomcat as a root user gives full system access to your application. If your application is hacked, hackers can have full control over your server. Always run your Tomcat server under a dedicated user.
But there is more. Tomcat has a catalina.policy file. In this file, a more fine-graded tweaking can be done. Developers can specify to which directories an application can have access to. Also restrictions to IP-addresses and ports can be done in the policy file. It is a good habit to always configure your server to only allow access to those resources you are sure of.