In many production environments, it is very useful to have the capability
to deploy a new web application, or undeploy an existing one, without having
to shut down and restart the entire container. In addition, you can request
an existing application to reload itself, even if you have not declared it
to be reloadable in the Tomcat 4 server
configuration file.

To support these capabilities, Tomcat 4 includes a web application
(installed by default on context path /manager) that supports
the following functions:

Deploy a new web application, on a specified context path, from
the uploaded contents of a WAR file.

Install a new web application, which can be anywhere on the
server's disks.

List the currently deployed web applications, as well as the
sessions that are currently active for those web apps.

Reload an existing web application, to reflect changes in the
contents of /WEB-INF/classes or /WEB-INF/lib.

List the OS and JVM property values.

List the available global JNDI resources, for use in deployment
tools that are preparing <ResourceLink> elements
nested in a <Context> deployment description.

List the available security roles defined in the user database.

Remove an installed web application.

Start a stopped application (thus making it available again).

Stop an existing application (so that it becomes unavailable), but
do not undeploy it.

If you have Tomcat configured to support multiple virtual hosts
(websites) you would need to configure a Manager for each.

There are three ways to use the Manager web application.

As an application with a user interface you use in your browser.
Here is an example URL where you can replace localhost with
your website host name: http://localhost/manager/html/ .

A minimal version using HTTP requests only which is suitable for use
by scripts setup by system administrators. Commands are given as part of the
request URI, and responses are in the form of simple text that can be easily
parsed and processed. See
Supported Manager Commands for more information.

The description below uses the variable name $CATALINA_HOME
to refer to the directory into which you have installed Tomcat 4,
and is the base directory against which most relative paths are
resolved. However, if you have configured Tomcat 4 for multiple
instances by setting a CATALINA_BASE directory, you should use
$CATALINA_BASE instead of $CATALINA_HOME for each of these
references.

It would be quite unsafe to ship Tomcat with default settings that allowed
anyone on the Internet to execute the Manager application on your server.
Therefore, the Manager application is shipped with the requirement that anyone
who attempts to use it must authenticate themselves, using a username and
password that have the role manager associated with them.
Further, there is no username in the default users file
($CATALINA_HOME/conf/tomcat-users.xml) that is assigned this
role. Therefore, access to the Manager application is completely disabled
by default.

To enable access to the Manager web application, you must either create
a new username/password combination and associate the role name
manager with it, or add the manager role
to some existing username/password combination. Exactly where this is done
depends on which Realm implementation you are using:

MemoryRealm - If you have not customized your
$CATALINA_HOME/conf/server.xml to select a different one,
Tomcat 4 defaults to an XML-format file stored at
$CATALINA_HOME/conf/tomcat-users.xml, which can be
edited with any text editor. This file contains an XML
<user> for each individual user, which might
look something like this:

<user name="craigmcc" password="secret" roles="standard,manager" />

which defines the username and password used by this individual to
log on, and the role names he or she is associated with. You can
add the manager role to the comma-delimited
roles attribute for one or more existing users, and/or
create new users with that assigned role.

JDBCRealm - Your user and role information is stored in
a database accessed via JDBC. Add the manager role
to one or more existing users, and/or create one or more new users
with this role assigned, following the standard procedures for your
environment.

JNDIRealm - Your user and role information is stored in
a directory server accessed via LDAP. Add the manager
role to one or more existing users, and/or create one or more new users
with this role assigned, following the standard procedures for your
environment.

The first time you attempt to issue one of the Manager commands
described in the next section, you will be challenged to log on using
BASIC authentication. The username and password you enter do not matter,
as long as they identify a valid user in the users database who possesses
the role manager.

In addition to the password restrictions the manager web application
could be restricted by the remote IP address or host by adding a
RemoteAddrValve or RemoteHostValve. Here is
an example of restricting access to the localhost by IP address:

All commands that the Manager application knows how to process are
specified in a single request URI like this:

http://{host}:{port}/manager/{command}?{parameters}

where {host} and {port} represent the hostname
and port number on which Tomcat is running, {command}
represents the Manager command you wish to execute, and
{parameters} represents the query parameters
that are specific to that command. In the illustrations below, customize
the host and port appropriately for your installation.

Most commands accept one or more of the following query parameters:

path - The context path (including the leading slash)
of the web application you are dealing with. To select the ROOT web
application, specify "/". NOTE -
It is not possible to perform administrative commands on the
Manager application itself.

war - URL of a web application archive (WAR) file,
pathname of a directory which contains the web application, or a
Context configuration ".xml" file. You can use URLs in any of the
following formats:

file:/absolute/path/to/a/directory - The absolute
path of a directory that contains the unpacked version of a web
application. This directory will be attached to the context path
you specify without any changes.

file:/absolute/path/to/a/webapp.war - The absolute
path of a web application archive (WAR) file. This is valid
only for the /deploy command, and is
the only acceptable format to that command.

jar:file:/absolute/path/to/a/warfile.war!/ - The
URL to a local web application archive (WAR) file. You can use any
syntax that is valid for the JarURLConnection class
for reference to an entire JAR file.

directory - The directory name for the web
applciation context in the Host's application base directory.

webapp.war - The name of a web application war file
located in the Host's application base directory.

Each command will return a response in text/plain format
(i.e. plain ASCII with no HTML markup), making it easy for both humans and
programs to read). The first line of the response wil begin with either
OK or FAIL, indicating whether the requested
command was successful or not. In the case of failure, the rest of the first
line will contain a description of the problem that was encountered. Some
commands include additional lines of information as described below.

Internationalization Note - The Manager application looks up
its message strings in resource bundles, so it is possible that the strings
have been translated for your platform. The examples below show the English
version of the messages.

Upload the web application archive (WAR) file that is specified as the
request data in this HTTP PUT request, install it into the appBase
directory of our corresponding virtual host, and start it on the context path
specified by the path request parameter. If no path
is specified the directory name or the war file name without the .war extension
is used as the path. The application can
later be undeployed (and the corresponding application directory removed)
by use of the /undeploy.

NOTE - Since this command requires an HTTP PUT request,
it is usable only from tools (such as the custom Ant tasks described below).
To install a new web application without copying, consider the
/install command described below. This command is the logical
opposite of the /undeploy command.

If installation and startup is successful, you will receive a response
like this:

OK - Deployed application at context path /foo

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Application already exists at path /foo

The context paths for all currently running web applications must be
unique. Therefore, you must either remove or undeploy the existing web
application using this context path, or choose a different context path
for the new one.

Encountered exception

An exception was encountered trying to start the new web application.
Check the Tomcat 4 logs for the details, but likely explanations include
problems parsing your /WEB-INF/web.xml file, or missing
classes encountered when initializing application event listeners and
filters.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

Install and start a new web application, attached to the specified context
path (which must not be in use by any other web application).
This command is the logical opposite of the /remove command.

There are a number of different ways the install command can be used.

Install a Directory or WAR by URL

Install a web application directory or ".war" file located on the Tomcat
server. If no path is specified, the directory name or the war file
name without the ".war" extension is used as the path. The war
parameter specifies a URL (including the file: scheme) for either
a directory or a web application archive (WAR) file. The supported syntax for
a URL referring to a WAR file is described on the Javadocs page for the
java.net.JarURLConnection class. Use only URLs that refer to
the entire WAR file.

In this example the web application located in the directory
/path/to/foo on the Tomcat server is installed as the
web application context named /footoo.

In this example the ".war" file /path/to/bar.war on the
Tomcat server is installed as the web application context named
/bar. Notice that there is no path parameter
so the context path defaults to the name of the web application archive
file without the ".war" extension.

http://localhost:8080/manager/install?war=jar:file:/path/to/bar.war!/

Install a Directory or War from the Host appBase

Install a web application directory or ".war" file located in your Host
appBase directory. If no path is specified the directory name
or the war file name without the ".war" extension is used as the path.

In this example the web application located in a sub directory named
foo in the Host appBase directory of the Tomcat server is
installed as the web application context named /foo. Notice
that there is no path parameter so the context path defaults
to the name of the web application directory.

http://localhost:8080/manager/install?war=foo

In this example the ".war" file bar.war located in your
Host appBase directory on the Tomcat server is installed as the web
application context named /bartoo.

http://localhost:8080/manager/install?path=/bartoo&war=bar.war

Install using a Context configuration ".xml" file

If the Host deployXML flag is set to true you can install a web
application using a Context configuration ".xml" file and an optional
".war" file or web application directory. The context path
is not used when installing a web application using a context ".xml"
configuration file.

A Context configuration ".xml" file can contain valid XML for a
web application Context just as if it were configured in your
Tomcat server.xml configuration file. Here is an
example:

Installation Notes

If the Host is configured with unpackWARs=true and you install a war
file, the war will be unpacked into a directory in your Host appBase
directory.

If the application war or directory is installed in your Host appBase
directory and either the Host is configured with autoDeploy=true or
liveDeploy=true, the Context path must match the directory name or
war file name without the ".war" extension.

For security when untrusted users can manage web applications, the
Host deployXML flag can be set to false. This prevents untrusted users
from installing web applications using a configuration XML file and
also prevents them from installing application directories or ".war"
files located outside of their Host appBase.

Install Response

If installation and startup is successful, you will receive a response
like this:

OK - Installed application at context path /foo

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Application already exists at path /foo

The context paths for all currently running web applications must be
unique. Therefore, you must either remove or undeploy the existing web
application using this context path, or choose a different context path
for the new one.

Document base does not exist or is not a readable directory

The URL specified by the war parameter must identify a
directory on this server that contains the "unpacked" version of a
web application, or the absolute URL of a web application archive (WAR)
file that contains this application. Correct the value specified by
the war parameter.

Encountered exception

An exception was encountered trying to start the new web application.
Check the Tomcat 4 logs for the details, but likely explanations include
problems parsing your /WEB-INF/web.xml file, or missing
classes encountered when initializing application event listeners and
filters.

Invalid application URL was specified

The URL for the directory or web application that you specified
was not valid. Such URLs must start with file:, and URLs
for a WAR file must end in ".war".

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

Context path must match the directory or WAR file name:

If the application war or directory is installed in your Host appBase
directory and either the Host is configured with autoDeploy=true or
liveDeploy=true, the Context path must match the directory name or
war file name without the ".war" extension.

Only web applications in the Host web application directory can
be installed

If the Host deployXML flag is set to false this error will happen
if an attempt is made to install a web application directory or
".war" file outside of the Host appBase directory.

List the context paths, current status (running or
stopped), and number of active sessions for all currently
deployed and installed web applications. A typical response immediately
after starting Tomcat might look like this:

Signal an existing application to shut itself down and reload. This can
be useful when the web application context is not reloadable and you have
updated classes or property files in the /WEB-INF/classes
directory or when you have added or updated jar files in the
/WEB-INF/lib directory.

NOTE: The /WEB-INF/web.xml
web application configuration file is not reread on a reload.
If you have made changes to your web.xml file you must stop
then start the web application.

If this command succeeds, you will see a response like this:

OK - Reloaded application at context path /examples

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Encountered exception

An exception was encountered trying to restart the web application.
Check the Tomcat 4 logs for the details.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

No context exists for path /foo

There is no deployed or installed application on the context path
that you specified.

No context path was specified

The path parameter is required.

Reload not supported on WAR deployed at path /foo

Currently, application reloading (to pick up changes to the classes or
web.xml file) is not supported when a web application is
installed directly from a WAR file. It only works when the web application
is installed from an unpacked directory. If you are using a WAR file,
you should remove and then install the
application again to pick up your changes.

WARNING - This command will delete the
contents of the web application directory and/or ".war" file if it exists within
the appBase directory (typically "webapps") for this virtual host
. The web application temporary work directory is also deleted. If
you simply want to take an application out of service, you should use the
/stop command instead.

Signal an existing application to gracefully shut itself down, and then
remove it from Tomcat (which also makes this context path available for
reuse later). This command is the logical opposite of the
/install command.

If this command succeeds, you will see a response like this:

OK - Removed application at context path /examples

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Encountered exception

An exception was encountered trying to remove the web application.
Check the Tomcat 4 logs for the details.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

No context exists for path /foo

There is no deployed or installed application on the context path
that you specified.

List the global JNDI resources that are available for use in resource
links for context configuration files. If you specify the type
request parameter, the value must be the fully qualified Java class name of
the resource type you are interested in (for example, you would specify
javax.sql.DataSource to acquire the names of all available
JDBC data sources). If you do not specify the type request
parameter, resources of all types will be returned.

Depending on whether the type request parameter is specfied
or not, the first line of a normal response will be:

OK - Listed global resources of all types

or

OK - Listed global resources of type xxxxx

followed by one line for each resource. Each line is composed of fields
delimited by colon characters (":"), as follows:

Global Resource Name - The name of this global JNDI resource,
which would be used in the global attribute of a
<ResourceLink> element.

List the security role names (and corresponding descriptions) that are
available in the org.apache.catalina.UserDatabase resource that
is linked to the users resource reference in the web.xml file
for the Manager web application. This would typically be used, for example,
by a deployment tool that wanted to create
<security-role-ref> elements to map security role names
used in a web application to the role names actually defined within the
container.

By default, the users resource reference is pointed at the
global UserDatabase resource. If you choose to utilize a
different user database per virtual host, you should modify the
<ResourceLink> element in the default
manager.xml context configuration file to point at the global
user database resource for this virtual host.

When this command is executed, the first line of the response will be:

OK - Listed security roles

followed by one line for each security role. Each line is composed of
fields delimited by colon characters (":") as follows:

Security Role Name - A security role name that is known to Tomcat
in the user database.

Description - Description of this security role (useful in
creating user interfaces for selecting roles.

If an error occurs, the response will start with FAIL and
include an error message. Possible causes for problems include:

Cannot resolve user database reference - A JNDI error prevented
the successful lookup of the org.apache.catalina.UserDatabase
resource. Check the Tomcat log files for a stack trace associated with
this error.

No user database is available - You have not configured a resource
reference for the users resource that points at an
appropriate user database instance. Check your manager.xml
file and ensure that you have created an appropriate
<ResourceLink> or
<ResourceParams> element for this resource.

Display the default session timeout for a web application, and the
number of currently active sessions that fall within ten-minute ranges of
their actual timeout times. For example, after restarting Tomcat and then
executing one of the JSP samples in the /examples web app,
you might get something like this:

Signal a stopped application to restart, and make itself available again.
Stopping and starting is useful, for example, if the database required by
your application becomes temporarily unavailable. It is usually better to
stop the web application that relies on this database rather than letting
users continuously encounter database exceptions.

If this command succeeds, you will see a response like this:

OK - Started application at context path /examples

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Encountered exception

An exception was encountered trying to start the web application.
Check the Tomcat 4 logs for the details.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

No context exists for path /foo

There is no deployed or installed application on the context path
that you specified.

Signal an existing application to make itself unavailable, but leave it
deployed or installed. Any request that comes in while an application is
stopped will see an HTTP error 404, and this application will show as
"stopped" on a list applications command.

If this command succeeds, you will see a response like this:

OK - Stopped application at context path /examples

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Encountered exception

An exception was encountered trying to stop the web application.
Check the Tomcat 4 logs for the details.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

No context exists for path /foo

There is no deployed or installed application on the context path
that you specified.

WARNING - This command will
delete the contents of the web application directory if it exists within the
appBase directory (typically "webapps") for this virtual host
. If you simply want to take an application out of service,
you should use the /stop command instead.

Signal an existing application to gracefully shut itself down, and
remove it from Tomcat (which also makes this context path available for
reuse later). In addition, the document root directory is removed, if it
exists in the appBase directory (typically "webapps") for
this virtual host. This command is the logical opposite of the
/deploy command.

If this command succeeds, you will see a response like this:

OK - Undeployed application at context path /examples

Otherwise, the response will start with FAIL and include an
error message. Possible causes for problems include:

Encountered exception

An exception was encountered trying to undeploy the web application.
Check the Tomcat 4 logs for the details.

Invalid context path was specified

The context path must start with a slash character. To reference the
ROOT web application use "/".

No context exists for path /foo

There is no deployed or installed application on the context path
that you specified.

In addition to the ability to execute Manager commands via HTTP requests,
as documented above, Tomcat 4 includes a convenient set of Task definitions
for the Ant (version 1.4 or later) build tool. In order to use these
commands, you must perform the following setup operations:

Now, you can execute commands like ant install to install th
applcation to a running instance of Tomcat, or ant reload to
tell Tomcat to reload it. Note also that most of the interesting values in
this build.xml file are defined as replaceable properties, so
you can override their values from the command line. For example, you might
consider it a security risk to include the real manager password in your
build.xml file's source code. To avoid this, omit the password
property, and specify it from the command line: