Context Descriptor in Tomcat 5

The context descriptor file, according to the Tomcat official documentation, is "used to define Tomcat specific configuration options, such as loggers, data sources, session manager configuration and more".

The file follows an XML syntax, and the name of the file is always the name of the web application, with a .xml extension. So, for this application, called MyFirst, the name of the context descriptor is MyFirst.xml.

Create a file called MyFirst.xml with the following contents:

<Context path="/MyFirst" docBase="MyFirst" debug="0" reloadable="true"/>

Save the file into $CATALINA_HOME/conf/Catalina/localhost/ directory.

With much older versions of Tomcat, such as the early Tomcat 3.x series or 4.0.x series, you had to add the context definitions inside server.xml. With Tomcat 5.x, the context descriptor provides a cleaner separation of web application configuration and the main Tomcat server configuration. An added benefit is that web applications deployed in this way do not require a stop and restart of the Tomcat server process. Tomcat should automatically pick it up while it is still running.

One of the things I really enjoy about Open Source software is that you can sometimes get useful insights from people smarter and more experienced than yourself. I had an interesting discussion with Josh Rehman on the relative merits of deploying web applications using the server.xml method or using the context descriptor method.

Josh's position is that the context descriptor method should become the canonical method for web application deployment for many reasons: the unreliability of server.xml edits propagating through the server, and the difficulty of removing those contexts that are already deployed.

I had not considered that position before, probably because I do not run Tomcat in a high volume, mission-critical environment. Things are different in the little corner of Asia where I stay and work. The traffic is much lower and you can pretty much reboot the server anytime you wish. So bringing down the Tomcat server process to add, modify or delete a context is feasible.

If, however, you have responsibilities for a large deployment of Tomcat servers, or just a Tomcat server running in a high volume environment, the game changes fundamentally. You will need something that allows for "on-the-fly" changes, and more importantly, you need a clear separation between server configuration parameters shared by all applications, and configurations for each individual web application. Although there are merits in keeping all configuration in one place, when you are pressed for time, you don't want to wade through an ultra-long configuration file to get at the parts you want to change or delete. I learned that painful lesson when adding a CD-RW drive to a running web server recently.