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.
  NOTE: If the path parameter is not explicitly specified then the path and the version will be derived using the standard Context naming rules from the config parameter or, if the config parameter is not present, the war parameter.
• version - The version of this web application as used by the parallel deployment feature. If you use parallel deployment wherever a path is required you must specify a version in addition to the path and it is the combination of path and version that must be unique rather than just the path.
  NOTE: If the path is not explicitly specified, the version parameter is ignored.
• war - URL of a web application archive (WAR) file, or 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.
  • 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.
  • 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 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.

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, deriving the name for the WAR file added to the appBase from the specified path. The application can later be undeployed (and the corresponding WAR file removed) by use of the /undeploy command.

This command is executed by an HTTP PUT request.

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.
• config : URL of a Context configuration ".xml" file in the format file:/absolute/path/to/a/context.xml. This must be the absolute path of a web application Context configuration ".xml" file which contains the Context configuration element.

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

This command is executed by an HTTP GET request. There are a number of different ways the deploy command can be used.

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

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

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

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

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

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

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

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

OK - Deployed application at context path /foo

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:webdav
/examples:running:0:examples
/manager:running:0:manager
/:running:0:ROOT
/test:running:0:test##2
/test:running:0:test##1

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.

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 deploy with the update parameter the application again to pick up your changes.

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.

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 global attribute 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.

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 one-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
<1 minutes: 1 sessions
1 - <2 minutes: 1 sessions

http://localhost:8080/manager/text/expire?path=/examples&idle=num

Display the session statistics (like the above /sessions command) and expire sessions that are idle for longer than num minutes. To expire all sessions, use &idle=0 .

OK - Session information for application at context path /examples
Default maximum session inactive interval 30 minutes
1 - <2 minutes: 1 sessions
3 - <4 minutes: 1 sessions
>0 minutes: 2 sessions were expired

Actually /sessions and /expire are synonyms for the same command. The difference is in the presence of idle parameter.

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.

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.

http://localhost:8080/manager/text/undeploy?path=/examples

WARNING - 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 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 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 named /foo

  There is no deployed application with the name that you specified.

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

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.

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

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

The response will look 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
  ...

http://localhost:8080/manager/text/sslConnectorCerts

The SSL Connector/Certs diagnostic lists the certificate chain that is currently configured for each virtual host.

The response will look something like this:

OK - Connector / Certificate Chain information
Connector[HTTP/1.1-8080]
SSL is not enabled for this connector
Connector[HTTP/1.1-8443]-_default_-RSA
[
[
  Version: V3
  Subject: CN=localhost, OU=Apache Tomcat PMC, O=The Apache Software Foundation, L=Wakefield, ST=MA, C=US
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
  ...

http://localhost:8080/manager/text/sslConnectorTrustedCerts

The SSL Connector/Certs diagnostic lists the trusted certificates that are currently configured for each virtual host.

The response will look something like this:

OK - Connector / Trusted Certificate information
Connector[HTTP/1.1-8080]
SSL is not enabled for this connector
Connector[AJP/1.3-8009]
SSL is not enabled for this connector
Connector[HTTP/1.1-8443]-_default_
[
[
  Version: V3
  Subject: CN=Apache Tomcat Test CA, OU=Apache Tomcat PMC, O=The Apache Software Foundation, L=Wakefield, ST=MA, C=US
  ...

http://localhost:8080/manager/text/sslReload?tlsHostName=name

Reload the TLS configuration files (the certificate and key files, this does not trigger a re-parsing of server.xml). To reload the files for all hosts don't specify the tlsHostName parameter.

OK - Reloaded TLS configuration for [_default_]

http://localhost:8080/manager/text/threaddump

Write a JVM thread dump.

The response will look something like this:

OK - JVM thread dump
2014-12-08 07:24:40.080
Full thread dump Java HotSpot(TM) Client VM (25.25-b02 mixed mode):

"http-nio-8080-exec-2" Id=26 cpu=46800300 ns usr=46800300 ns blocked 0 for -1 ms waited 0 for -1 ms
   java.lang.Thread.State: RUNNABLE
        locks java.util.concurrent.ThreadPoolExecutor$Worker@1738ad4
        at sun.management.ThreadImpl.dumpThreads0(Native Method)
        at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:446)
        at org.apache.tomcat.util.Diagnostics.getThreadDump(Diagnostics.java:440)
        at org.apache.tomcat.util.Diagnostics.getThreadDump(Diagnostics.java:409)
        at org.apache.catalina.manager.ManagerServlet.threadDump(ManagerServlet.java:557)
        at org.apache.catalina.manager.ManagerServlet.doGet(ManagerServlet.java:371)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
...

http://localhost:8080/manager/text/vminfo

Write some diagnostic information about Java Virtual Machine.

The response will look something like this:

OK - VM info
2014-12-08 07:27:32.578
Runtime information:
  vmName: Java HotSpot(TM) Client VM
  vmVersion: 25.25-b02
  vmVendor: Oracle Corporation
  specName: Java Virtual Machine Specification
  specVersion: 1.8
  specVendor: Oracle Corporation
  managementSpecVersion: 1.2
  name: ...
  startTime: 1418012458849
  uptime: 393855
  isBootClassPathSupported: true

OS information:
...

http://localhost:8080/manager/text/save

If specified without any parameters, this command saves the current configuration of the server to server.xml. The existing file will be renamed as a backup if required.

If specified with a path parameter that matches the path of a deployed web application then the configuration for that web application will be saved to an appropriately named context.xml file in the xmlBase for the current Host.

To use the command a StoreConfig MBean must be present. Typically this is configured using the StoreConfigLifecycleListener.

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

This takes the form:

http://webserver/manager/jmxproxy/?qry=STUFF

Where STUFF is the JMX query you wish to perform. For example, here are some queries you might wish to run:

• qry=*%3Atype%3DRequestProcessor%2C* --> type=RequestProcessor which will locate all workers which can process requests and report their state.
• qry=*%3Aj2eeType=Servlet%2c* --> j2eeType=Servlet which return all loaded servlets.
• qry=Catalina%3Atype%3DEnvironment%2Cresourcetype%3DGlobal%2Cname%3DsimpleValue --> Catalina:type=Environment,resourcetype=Global,name=simpleValue which look for a specific MBean by the given name.

You'll need to experiment with this to really understand its capabilities If you provide no qry parameter, then all of the MBeans will be displayed. We really recommend looking at the tomcat source code and understand the JMX spec to get a better understanding of all the queries you may run.

The JXMProxyServlet also supports a "get" command that you can use to fetch the value of a specific MBean's attribute. The general form of the get command is:

http://webserver/manager/jmxproxy/?get=BEANNAME&att=MYATTRIBUTE&key=MYKEY

You must provide the following parameters:

1. get: The full bean name
2. att: The attribute you wish to fetch
3. key: (optional) The key into a CompositeData MBean attribute

If all goes well, then it will say OK, otherwise an error message will be shown. For example, let's say we wish to fetch the current heap memory data:

http://webserver/manager/jmxproxy/?get=java.lang:type=Memory&att=HeapMemoryUsage

Or, if you only want the "used" key:

http://webserver/manager/jmxproxy/
 ?get=java.lang:type=Memory&att=HeapMemoryUsage&key=used

Now that you can query an MBean, its time to muck with Tomcat's internals! The general form of the set command is :

http://webserver/manager/jmxproxy/?set=BEANNAME&att=MYATTRIBUTE&val=NEWVALUE

So you need to provide 3 request parameters:

1. set: The full bean name
2. att: The attribute you wish to alter
3. val: The new value

If all goes ok, then it will say OK, otherwise an error message will be shown. For example, lets say we wish to turn up debugging on the fly for the ErrorReportValve. The following will set debugging to 10.

http://localhost:8080/manager/jmxproxy/
 ?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost
 &att=debug&val=10

and my result is (YMMV):

Result: ok

Here is what I see if I pass in a bad value. Here is the URL I used, I try set debugging equal to 'cow':

http://localhost:8080/manager/jmxproxy/
 ?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost
 &att=debug&val=cow

When I try that, my result is

Error: java.lang.NumberFormatException: For input string: "cow"

The invoke command enables methods to be called on MBeans. The general form of the command is:

http://webserver/manager/jmxproxy/
 ?invoke=BEANNAME&op=METHODNAME&ps=COMMASEPARATEDPARAMETERS

For example, to call the findConnectors() method of the Service use:

http://localhost:8080/manager/jmxproxy/
 ?invoke=Catalina%3Atype%3DService&op=findConnectors&ps=

Using Ant version 1.6.2 or later, the Catalina tasks offer the option to capture their output in properties or external files. They support directly the following subset of the <redirector> type attributes:

A couple of additional attributes can also be specified:

They also support the embedded <redirector> element in which you can specify its full set of attributes, but input, inputstring and inputencoding that, even if accepted, are not used because they have no meaning in this context. Refer to ant manual for details on <redirector> element attributes.

Here is a sample build file extract that shows how this output redirection support can be used:

    <target name="manager.deploy"
        depends="context.status"
        if="context.notInstalled">
        <deploy url="${mgr.url}"
            username="${mgr.username}"
            password="${mgr.password}"
            path="${mgr.context.path}"
            config="${mgr.context.descriptor}"/>
    </target>

    <target name="manager.deploy.war"
        depends="context.status"
        if="context.deployable">
        <deploy url="${mgr.url}"
            username="${mgr.username}"
            password="${mgr.password}"
            update="${mgr.update}"
            path="${mgr.context.path}"
            war="${mgr.war.file}"/>
    </target>

    <target name="context.status">
        <property name="running" value="${mgr.context.path}:running"/>
        <property name="stopped" value="${mgr.context.path}:stopped"/>

        <list url="${mgr.url}"
            outputproperty="ctx.status"
            username="${mgr.username}"
            password="${mgr.password}">
        </list>

        <condition property="context.running">
            <contains string="${ctx.status}" substring="${running}"/>
        </condition>
        <condition property="context.stopped">
            <contains string="${ctx.status}" substring="${stopped}"/>
        </condition>
        <condition property="context.notInstalled">
            <and>
                <isfalse value="${context.running}"/>
                <isfalse value="${context.stopped}"/>
            </and>
        </condition>
        <condition property="context.deployable">
            <or>
                <istrue value="${context.notInstalled}"/>
                <and>
                    <istrue value="${context.running}"/>
                    <istrue value="${mgr.update}"/>
                </and>
                <and>
                    <istrue value="${context.stopped}"/>
                    <istrue value="${mgr.update}"/>
                </and>
            </or>
        </condition>
        <condition property="context.undeployable">
            <or>
                <istrue value="${context.running}"/>
                <istrue value="${context.stopped}"/>
            </or>
        </condition>
    </target>

WARNING: even if it doesn't make many sense, and is always a bad idea, calling a Catalina task more than once, badly set Ant tasks depends chains may cause that a task be called more than once in the same Ant run, even if not intended to. A bit of caution should be exercised when you are capturing output from that task, because this could lead to something unexpected:

• when capturing in a property you will find in it only the output from the first call, because Ant properties are immutable and once set they cannot be changed,
• when capturing in a file, each run will overwrite it and you will find in it only the last call output, unless you are using the append="true" attribute, in which case you will see the output of each task call appended to the file.