Tomcat Deploy Procedures: A Complete

Guide to Web Application Deployment

With Apache Tomcat
Apache Tomcat offers users a lot of flexibility when deploying web applications. Tomcat
is lightweight, and starts up in seconds, as opposed to the minutes it takes a stack-based
Java EE server to start, so traditional startup deployment is feasible. However, Tomcat
also supports a variety of hot deployment options, allowing users to roll out new
applications, or even update existing ones, while the server is still running.
In this guide, we'll explore all the options available to you when deploying an application
on your Tomcat server, from a simple startup deployment, to tools that can automate hot
deployment of your application across multiple running Tomcat servers.
Tip: Tcat makes deployment cycles take seconds instead of minutes. Deployment
packages allow you to deploy the latest versions of all your applications to groups of
servers with a single click. Repository and rollback capabilities that integrate with
Maven allow you to fully integrate Tcat into your development cycle.

Startup Deployment
Also knowns as folder deployment, startup deployment is the easiest way to deploying a
web application to your server.
To have Tomcat deploy an application automatically when it starts, simple copy either an
uncompressed web application (also known as an "exploded" application) or a
compressed application, or WAR, to the appBase folder specified in your Host
configuration.
When Tomcat starts, it will deploy all applications in the appBase, in the following order:
1. Applications defined by Context elements in either
"$CATALINA_BASE/conf/server.xml" (discouraged),
"$CATALINA_BASE/conf/[EngineName]/[HostName]/[ApplicationName].xml",
"or $CATALINA_BASE/webapps/[ApplicationName]/META-INF/context.xml"
2. Uncompressed (exploded) applications located in the appBase without Context
Descriptors.
3. docBase applications that are compressed in WAR files, along with WARs
associated with an existing application, which will be used to automatically
redeploy the application.
To deploy a new application, Tomcat copies its directory structure to the relevant context
path in its base webapps folder, creating directories as needed. If the application provides

its own Context.xml, this is copied to "$CATALINA_BASE/conf/[EngineName]/

[HostName]/[ApplicationName].xml", provided this file does not already exist.

Hot Deployment
The big downfall of startup deployment is that it requires a full server restart to make any
changes to the application, or deploy new applications, even if the application doesn't
have any elements that would require a restart for it to function.
To remedy this situation, Tomcat provides a number of "hot deployment" options, which
simply means that any deployments, redeployments, and adjustments to applications are
made while the server is still running, rather than requiring it to stop.
There are a number of ways to use hot deployment with Tomcat. In this section, we'll go
over the most common: Host autoDeploy, the Tomcat Manager, and the Tomcat Client
Deployer.
Host autoDeploy
The most recent versions of Tomcat support a number of hot deployment features right
out of the box. These features are enabled on a per-Host basis, by setting the
"autoDeploy" attribute to "true".
Here are some of the things you can do once you've enabled hot deployment:

Automatically deploy exploded or compressed applications by placing them in the

appBase
Re-deploy existing applications by copying an updated WAR file into the appBase
Use WatchedResource elements to initiate application re-deploy whenever the
defined resource is updated (for example, WEB-INF/web.xml)

For a complete list of autoDeploy-enabled hot deploy features, visit the Apache project
website.
Deployment with Tomcat Manager
The Tomcat Manager is a lightweight administrative tool included with all standard
distributions of Apache Tomcat, that provides a wide variety of deployment
functionalities, including a number of hot deployment commands.
Manager commands are sent in a standard URI format, as follows:
http://[host]:[port]/manager/[command]?[parameters]
Using the Manager, you can deploy an application to a running Tomcat server from pretty
much anywhere - there are usages for remote deployment, local path deployment,

deployment from WAR, deployment from the appBase, and even deployment by calling a
context.xml file that provides a docBase path.
Manager can also remotely reload, undeploy (careful, this means delete), start, and stop
applications.
To make sure that Tomcat is secure out of the box, Manager and its features are disabled
by default, and it takes more than a little wrangling to get it up and running.
For more information about using the Manager application on your server, including a list
of commands and some example usages, please check out our helpful Tomcat Manager
Guide.
Deployment with the Tomcat Client Deployer
The Tomcat Client Deployer (TCD) is a multi-component Java package that uses a
variety of technologies to validate, compile, compress, and deploy your web applications.
TCD is basically a bundle of Ant tasks that execute functions of the Jasper JSP Engine,
JDK, and Catalina engine (including the Tomcat Manager) to quickly move applications
from your hard drive to your running Tomcat server.
TCD is not included with standard distributions of Tomcat. You can download it
separately from the Tomcat project site. You can decompress it anywhere you want; it
doesn't need to be in a Tomcat directory. If you haven't installed it already, you'll also
need to download and install Apache Ant in order for TCD to run. Note that a
configured, running instance of the Tomcat Manager application is required for TCD to
work.
To deploy an application using TCD, you will need to create and edit a file named
"deployer.properties", which should be located in the root directory of the TCD package.
This file will look something like this, substituting [values] and {variables}:
build=${build}/webapp/${path}
webapp=[path/to/target/exploded/application]
path=[DesiredContextPath]
url=[http://[host]:[port]/path/to/manager/webapp]
username=[UserWithManagerRole]
password=[TomcatManagerPassword]
Once you have configured this file, run TCD with the included Ant script. The default
target, "compile", will validate and compile the web application as a WAR file at the

specified "build" location. Other targets with self-explanatory features include deploy,
undeploy, start, reload, and stop.

Other Hot Deployment Scenarios

Aside from the three basic hot deployment methods, there are a few other ways you may
want to hot deploy to Tomcat.
In this section, we'll learn how to set up an Integrated Development Environment to hot
deploy all changes to your Tomcat server, and look at how to deal with the complex
problem of hot deployment across multiple servers in a production environment.
Hot Deployment to Tomcat with an IDE
Integrated Development Environments can speed up many aspects of Java web
application development, including deployment of changes to the server.
Thanks to Tomcat's native support for hot deployment, getting Tomcat to update
applications with your changes as you make them is a deceptively simple problem. The
real hassle isn't getting Tomcat to hot deploy changes - it's getting your IDE talking to
Tomcat. Here's a simple step-by-step guide:
1. Configure your IDE to recognize Tomcat as a server environment. Thanks to
Tomcat's popularity, most IDEs offer plug-ins adding Tomcat support to their
environment. For an example of this, check out Tomcat Eclipse, our simple,
illustrated guide to using Tomcat in conjunction with the popular Eclipse IDE.
2. Give your IDE write-access to your application's "WEB-INF/classes" directory.
3. Configure Tomcat to reload classes when they are changed, by setting the
"reloadable" attribute to "true" for the relevant Context and Web-App elements in
your Tomcat configuration files.