The Jakarta Project
</title></head></meta></title></head></meta>
</title></head></meta></title></head></meta>
</title></head></meta></title></head></meta>
<table><tr>
<td width=124 valign=top>
<a href=http://www.gnu-darwin.org><img src=http://www.gnu-darwin.org/hexley-gd-sm.png border=0><br>
<!-- SiteSearch Google -->
<p>
<script type=
Google

The Tomcat Servlet/JSP Container " align="right" src="./images/tomcat.gif">

Links

Getting Started

Administrators

Application Developers

Catalina Developers

Jasper Developers

Manager App HOW-TO

Introduction

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 a specified directory or WAR file pathname.
  • List the currently deployed web applications, as well as the sessions that are currently active for those web apps.
  • Cause an existing application to be reloaded.
  • Undeploy an existing web application.
  • Stop an existing application (so that it becomes unavailable), but do not undeploy it.
  • Start a stopped application (thus making it available again).

Since Manager is itself a web application, it interacts with you using standard HTTP requests and responses. However, it's "user interface" is minimal, because it is intended to be accessed from scripts set up by the system administrator. For this reason, 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.

Future versions of Tomcat 4 will include administrative functionality that is presented in (at least) the following forms:

  • As web services, so that Tomcat administration can be easily integrated into remote and/or non-Java mnagement environments.
  • As a web application with a nice user interface (built on top of the web services processing layer) for easy Tomcat administration via a web browser.
Configuring Manager Application Access

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 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 Tomcat 4 defaults to an XML-format file stored at 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 attriute 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.

Supported Manager Commands

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 a zero-length string. NOTE - It is not possible to perform administrative commands on the Manager application itself.
  • war - URL of a web application archive (WAR) file, or pathname of a directory, that contains the web application. 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.
    • 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.
    • jar:http://hostname:port/path/to/a/warfile.war!/ - You can also deploy web applications from a remote JAR file. You can use any syntax that is valid for the JarURLConnection class for reference to an entire JAR file.

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.

Deploy A New Application

http://localhost:8080/manager/install?path=/foo&war=file:/path/to/foo



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

Install and start a new web application, attached to the specified context path (which must not be in use by any other web application). 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.

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 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 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, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.

  • No context path was specified
    The path parameter is required.
List Currently Deployed Applications

http://localhost:8080/manager/list

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


OK - Listed applications for virtual host localhost

/webdav:running:0

/examples:running:0

/manager:running:0

/:running:0

Reload An Existing Application

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

Signal an existing application to shut itself down and reload. This can be useful when you've recompiled classes on an application that is not configured with the reloadable="true" attribute in its <Context> entry in recognized by Tomcat.

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, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.

  • No context exists for path /foo

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

  • No context path was specified
    The path parameter is required.
Session Statistics

http://localhost:8080/manager/sessions?path=/examples

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:


OK - Session information for application at context path /examples

Default maximum session inactive interval 30 minutes

30 - <40 minutes:1 sessions

Start an Existing Application

http://localhost:8080/manager/start?path=/examples

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 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, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.

  • No context exists for path /foo

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

  • No context path was specified
    The path parameter is required.
Stop an Existing Application

http://localhost:8080/manager/stop?path=/examples

Signal an existing application to make itself unavailable, but leave it deployed. 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 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, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.

  • No context exists for path /foo

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

  • No context path was specified
    The path parameter is required.
Undeploy an Existing Application

http://localhost:8080/manager/remove?path=/examples

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).

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 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, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.

  • No context exists for path /foo

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

  • No context path was specified
    The path parameter is required.

Copyright © 1999-2002, Apache Software Foundation