Restarting Applications Without Restarting Tomcat

If you modify a JSP page, Tomcat recompiles it automatically when the page is next requested. But if the page uses a JAR or class file under the application's WEB-INF directory and you update one of them, Tomcat normally won't notice the change until you restart it.

One way to avoid restarts for an application is to provide a <Context> element for the application in Tomcat's server.xml file that specifies a reloadable attribute of TRue. That will cause Tomcat to look for changes not only in JSP pages that are requested directly, but also for changes in classes and libraries under the WEB-INF directory that the pages use. For example, to write such a <Context> element for an application named mcb, you could add a line like this to Tomcat's server.xml file:

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

The <Context> element attributes tell Tomcat four things:

path

Indicates the URL that maps to pages from the application context. The value is the part of the URL that follows the hostname and port number.

docBase

Indicates where the application context directory is located, relative to the webapps directory in the Tomcat tree.

debug

Sets the context debugging level. A value of zero disables debug output; higher numbers generate more output.

reloadable

Specifies Tomcat recompilation behavior when a client requests a JSP page located in the application context. By default, Tomcat recompiles a page only after noticing a modification to the page itself. Setting reloadable to TRue tells Tomcat to also check any classes or libraries stored under the application's WEB-INF directory that the page uses.

After modifying server.xml to add the <Context> element, restart Tomcat to make the change take effect.

Having Tomcat check for class and library changes can be extremely useful during application development to avoid repeated restarts. However, as you might expect, automatic class checking adds a lot of processing overhead and incurs a significant performance penalty. It's better used on development systems than on production systems.

Another way to get Tomcat to recognize application changes without restarting the entire server is to use the Manager application. This enables you to reload applications on request from a browser, without the overhead caused by enabling the reloadable attribute. The Manager application is invoked using the path /manager at the end of the URL by which you access your Tomcat server. The URL also includes the command that you want to execute. For example, the following request shows which contexts are running:

http://localhost:8080/manager/list 

To shut down and reload the mcb application without restarting Tomcat, use a URL like this:

http://localhost:8080/manager/reload?path=/mcb 

For more information on using the Manager application and what its allowable commands are, see the Manager App HOW-TO:

http://tomcat.apache.org/tomcat-5.0-doc/manager-howto.html

This document may also be available locally by following the documentation link on your Tomcat server's home page. Note particularly the part that describes how to set up a Tomcat user with the manager role, because you'll need to provide a name and password to gain access to the Manager application. By default, user records are defined in Tomcat's tomcat-users.xml configuration file. The tomcat directory of the recipes distribution contains information on storing Tomcat user records in MySQL instead.