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/text/{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.
• version – The version of this web application as used by the parallel deployment feature,
• 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.
• file:/absolute/path/to/a/context.xml – The absolute path of a web application Context configuration “.xml” file which contains the Context configuration element.
• directory – The directory name for the web application context in the Host’s application base directory.
• 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 will 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 Remotely

http://localhost:8080/manager/text/deploy?path=/foo

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 , using the directory name or the war file name without the .war extension as the path. The application can later be undeployed (and the corresponding application directory removed) by use of the /undeploy command.

The .WAR file may include Tomcat specific deployment configuration, by including a Context configuration XML file in /META-INF/context.xml.

URL parameters include:

• update: When set to true, any existing update will be undeployed first. The default value is set to false.
• tag: Specifying a tag name, this allows associating the deployed webapp with a tag or label. If the web application is undeployed, it can be later redeployed when needed using only the tag.

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 undeploy the existing web application using this context path, or choose a different context path for the new one. The update parameter may be specified as a parameter on the URL, with a value of true to avoid this error. In that case, an undeploy will be performed on an existing application before performing the deployment.

• Encountered exception

An exception was encountered trying to start the new web application. Check the Tomcat 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.

Deploy A New Application from a Local Path

Deploy 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 /undeploy command.

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

Deploy a previously deployed webapp

This can be used to deploy a previously deployed web application, which has been deployed using the tagattribute. Note that the work directory for the Manager webapp will contain the previously deployed WARs; removing it would make the deployment fail.

http://localhost:8080/manager/text/deploy?path=/footoo&tag=footag

Deploy a Directory or WAR by URL

Deploy 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 thejava.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 deployed as the web application context named /footoo.

http://localhost:8080/manager/text/deploy?path=/footoo&war=file:/path/to/foo

In this example the “.war” file /path/to/bar.war on the Tomcat server is deployed 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/text/deploy?war=jar:file:/path/to/bar.war!/

Deploy a Directory or War from the Host appBase

Deploy a web application directory or “.war” file located in your Host appBase directory. 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 deployed as the web application context named /foo. Notice that the context path used is the name of the web application directory.

http://localhost:8080/manager/text/deploy?war=foo

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

http://localhost:8080/manager/text/deploy?war=bar.war

Deploy using a Context configuration “.xml” file

If the Host deployXML flag is set to true you can deploy 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 deploying 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:

<Context path=”/foobar” docBase=”/path/to/application/foobar”>

</Context>

When the optional war parameter is set to the URL for a web application “.war” file or directory it overrides any docBase configured in the context configuration “.xml” file.

Here is an example of deploying an application using a Context configuration “.xml” file.

http://localhost:8080/manager/text/deploy?config=file:/path/context.xml

Here is an example of deploying an application using a Context configuration “.xml” file and a web application “.war” file located on the server.

http://localhost:8080/manager/text/deploy

?config=file:/path/context.xml&war=jar:file:/path/bar.war!/

Deployment Notes

If the Host is configured with unpackWARs=true and you deploy 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 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 deploying web applications using a configuration XML file and also prevents them from deploying application directories or “.war” files located outside of their Host appBase.

Deploy Response

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 undeploy the existing web application using this context path, or choose a different context path for the new one. The update parameter may be specified as a parameter on the URL, with a value of true to avoid this error. In that case, an undeploy will be performed on an existing application before performing the deployment.

• 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 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 withfile:, 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 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 deploy a web application directory or “.war” file outside of the Host appBase directory.

List Currently Deployed Applications

http://localhost:8080/manager/text/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/text/reload?path=/examples

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.

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 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 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 deployed directly from a WAR file. It only works when the web application is deployed from an unpacked directory. If you are using a WAR file, you should undeploy and then deploy or deploywith the update parameter the application again to pick up your changes.

List OS and JVM Properties

http://localhost:8080/manager/text/serverinfo

Lists information about the Tomcat version, OS, and JVM properties.

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

• Encountered exception

An exception was encountered trying to enumerate the system properties. Check the Tomcat logs for the details.

List Available Global JNDI Resources

http://localhost:8080/manager/text/resources[?type=xxxxx]

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 specified 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 globalattribute of a <ResourceLink> element.
• Global Resource Type – The fully qualified Java class name of this global JNDI resource

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

• Encountered exception

An exception was encountered trying to enumerate the global JNDI resources. Check the Tomcat logs for the details.

• No global JNDI resources are available

The Tomcat server you are running has been configured without global JNDI resources.

Session Statistics

http://localhost:8080/manager/text/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/text/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 start the web application. Check the Tomcat 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 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/text/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 stop the web application. Check the Tomcat 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 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/text/undeploy?path=/examples

This command will delete any web application artifacts that exist within appBase directory (typically “webapps”) for this virtual host. This will delete the application .WAR, if present, the application directory resulting either from a deploy in unpacked form or from .WAR expansion as well as the XML Context definition from $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. 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 theappBase directory (typically “webapps”) for this virtual host. This command is the logical opposite of the /deploycommand.

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 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 application on the context path that you specified.

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

Finding memory leaks

http://localhost:8080/manager/text/findleaks[?statusLine=[true|false]]

The find leaks diagnostic triggers a full garbage collection. It should be used with extreme caution on production systems.

The find leaks diagnostic attempts to identify web applications that have caused memory leaks when they were stopped, reloaded or undeployed. Results should always be confirmed with a profiler. The diagnostic uses additional functionality provided by the StandardHost implementation. It will not work if a custom host is used that does not extend StandardHost.

Explicitly triggering a full garbage collection from Java code is documented to be unreliable. Furthermore, depending on the JVM used, there are options to disable explicit GC triggering, like -XX:+DisableExplicitGC. If you want to make sure, that the diagnostics were successfully running a full GC, you will need to check using tools like GC logging, JConsole or similar.

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

/leaking-webapp

If you wish to see a status line included in the response then include the statusLine query parameter in the request with a value of true.

Each context path for a web application that was stopped, reloaded or undeployed, but which classes from the previous runs are still loaded in memory, thus causing a memory leak, will be listed on a new line. If an application has been reloaded several times, it may be listed several times.

If the command does not succeed, the response will start with FAIL and include an error message.

Connector SSL diagnostics

http://localhost:8080/manager/text/sslConnectorCiphers

The SSL Connector/Ciphers diagnostic lists the SSL ciphers that are currently configured for each connector. For BIO and NIO, the names of the individual cipher suites are listed. For APR, the value of SSLCipherSuite is returned.

The response will ook something like this:

OK – Connector / SSL Cipher information

Connector[HTTP/1.1-8080]

SSL is not enabled for this connector

Connector[HTTP/1.1-8443]

TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

…

Server Status

From this link , you can view information about the server.

First, you have the server and JVM version number, JVM provider, OS name and number followed by the architecture type.

Second, there is several information about the memory usage of the JVM (available, total and max memory).

• Then, there is information about the Tomcat AJP and HTTP connectors. The same information is available for both of them :

Threads information : Max threads, min and max spare threads, current thread count and current thread busy.

Request information : Max processing time and processing time, request and error count, bytes received and sent.

• A table showing Stage, Time, Bytes Sent, Bytes Receive, Client, VHost and Request. All existing threads are listed in the table. Here is the list of the possible thread stages :

“Parse and Prepare Request” : The request headers are being parsed or the necessary preparation to read the request body (if a transfer encoding has been specified) is taking place.

“Service” : The thread is processing a request and generating the response. This stage follows the “Parse and Prepare Request” stage and precedes the “Finishing” stage. There is always at least one thread in this stage (the server-status page).

“Finishing” : The end of the request processing. Any remainder of the response still in the output buffers is sent to the client. This stage is followed by “Keep-Alive” if it is appropriate to keep the connection alive or “Ready” if “Keep-Alive” is not appropriate.

“Keep-Alive” : The thread keeps the connection open to the client in case the client sends another request. If another request is received, the next stage will br “Parse and Prepare Requst”. If no request is received before the keep alive times out, the connection will be closed and the next stage will be “Ready”.

“Ready” : The thread is at rest and ready to be used.