<?xml version="1.0"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!DOCTYPE document [
  <!ENTITY project SYSTEM "project.xml">
]>
<document url="manager-howto.html">

    &project;

    <properties>
        <author email="craigmcc@apache.org">Craig R. McClanahan</author>
        <title>Manager App HOW-TO</title>
    </properties>

<body>

<section name="Table of Contents">

<p>
<a href="#Introduction">Introduction</a><br />
<a href="#Configuring Manager Application Access">
Configuring Manager Application Access</a><br />
<a href="#Supported Manager Commands">Supported Manager Commands</a><br />
<blockquote>
<a href="#Deploy A New Application Remotely">Deploy A New Application Remotely</a><br />
<a href="#Deploy A New Application from a Local Path">Deploy A New Application from a Local Path</a><br />
<a href="#List Currently Deployed Applications">
List Currently Deployed Applications</a><br />
<a href="#Reload An Existing Application">Reload An Existing Application</a><br />
<a href="#List OS and JVM Properties">List OS and JVM Properties</a><br />
<a href="#List Available Global JNDI Resources">
List Available Global JNDI Resources</a><br />
<a href="#List Available Security Roles">List Available Security Roles</a><br />
<a href="#Session Statistics">Session Statistics</a><br />
<a href="#Start an Existing Application">Start an Existing Application</a><br />
<a href="#Stop an Existing Application">Stop an Existing Application</a><br />
<a href="#Undeploy an Existing Application">
Undeploy an Existing Application</a><br />
</blockquote>
<a href="#Executing Manager Commands With Ant">
Executing Manager Commands With Ant</a><br />
<a href="#Using the JMX Proxy Servlet">
Using the JMX Proxy Servlet</a><br />
<blockquote>
<a href="#What is JMX Proxy Servlet">What is JMX Proxy Servlet?</a><br />
<a href="#JMX Query command">Query command</a><br />
<a href="#JMX Set command">Set command</a><br />
</blockquote>
</p>

</section>

<section name="Introduction">

<p>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 <code>reloadable</code> in the Tomcat 5 server
configuration file.</p>

<p>To support these capabilities, Tomcat 5 includes a web application
(installed by default on context path <code>/manager</code>) that supports
the following functions:</p>
<ul>
<li>Deploy a new web application from the uploaded contents of a WAR file.</li>
<li>Deploy a new web application, on a specified context path, from the
    server file system.</li>
<li>List the currently deployed web applications, as well as the
    sessions that are currently active for those web apps.</li>
<li>Reload an existing web application, to reflect changes in the
    contents of <code>/WEB-INF/classes</code> or <code>/WEB-INF/lib</code>.
    </li>
<li>List the OS and JVM property values.</li>
<li>List the available global JNDI resources, for use in deployment
    tools that are preparing <code>&lt;ResourceLink&gt;</code> elements
    nested in a <code>&lt;Context&gt;</code> deployment description.</li>
<li>List the available security roles defined in the user database.</li>
<li>Start a stopped application (thus making it available again).</li>
<li>Stop an existing application (so that it becomes unavailable), but
    do not undeploy it.</li>
<li>Undeploy a deployed web application and delete its document base
    directory (unless it was deployed from file system).</li>
</ul>

<p>A default Tomcat installation includes the manager. To add an instance of the
Manager web application <code>Context</code> to a new host install the
<code>manager.xml</code> context configuration file in the
<code>$CATALINA_HOME/conf/[enginename]/[hostname]</code> folder. Here is an
example:
<pre>
&lt;Context path="/manager" debug="0" privileged="true"
         docBase="/usr/local/kinetic/tomcat5/server/webapps/manager"&gt;
&lt;/Context&gt;
</pre>
</p>

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

<p>There are three ways to use the <code>Manager</code> web application.
<ul>
<li>As an application with a user interface you use in your browser.
Here is an example URL where you can replace <code>localhost</code> with
your website host name:  <code>http://localhost/manager/html/</code> .</li>
<li>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 <a href="#Supported Manager Commands">
Supported Manager Commands</a> for more information.</li>
<li>A convenient set of task definitions for the <em>Ant</em>
(version 1.4 or later) build tool.  See
<a href="#Executing Manager Commands With Ant">Executing Manager Commands
With Ant</a> for more information.</li>
</ul>
</p>

</section>

<section name="Configuring Manager Application Access">

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

<p>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 <strong>manager</strong> associated with them.
Further, there is no username in the default users file
(<conf>$CATALINA_HOME/conf/tomcat-users.xml</conf>) that is assigned this
role.  Therefore, access to the Manager application is completely disabled
by default.</p>

<p>To enable access to the Manager web application, you must either create
a new username/password combination and associate the role name
<strong>manager</strong> with it, or add the <strong>manager</strong> role
to some existing username/password combination.  Exactly where this is done
depends on which <code>Realm</code> implementation you are using:</p>
<ul>
<li><em>MemoryRealm</em> - If you have not customized your
    <code>$CATALINA_HOME/conf/server.xml</code> to select a different one,
    Tomcat 5 defaults to an XML-format file stored at
    <code>$CATALINA_HOME/conf/tomcat-users.xml</code>, which can be
    edited with any text editor.  This file contains an XML
    <code>&lt;user&gt;</code> for each individual user, which might
    look something like this:
<source>
&lt;user name="craigmcc" password="secret" roles="standard,manager" /&gt;
</source>
    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 <strong>manager</strong> role to the comma-delimited
    <code>roles</code> attribute for one or more existing users, and/or
    create new users with that assigned role.</li>
<li><em>JDBCRealm</em> - Your user and role information is stored in
    a database accessed via JDBC.  Add the <strong>manager</strong> 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.</li>
<li><em>JNDIRealm</em> - Your user and role information is stored in
    a directory server accessed via LDAP.  Add the <strong>manager</strong>
    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.</li>
</ul>

<p>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 <strong>manager</strong>.</p>

<p>In addition to the password restrictions the manager web application
could be restricted by the remote IP address or host by adding a
<code>RemoteAddrValve</code> or <code>RemoteHostValve</code>.  Here is
an example of restricting access to the localhost by IP address:
<pre>
&lt;Context path="/manager" debug="0" privileged="true"
         docBase="/usr/local/kinetic/tomcat5/server/webapps/manager"&gt;
         &lt;Valve className="org.apache.catalina.valves.RemoteAddrValve"
                allow="127\.0\.0\.1"/&gt;
&lt;/Context&gt;
</pre>
</p>
</section>


<section name="Supported Manager Commands">

<p>All commands that the Manager application knows how to process are
specified in a single request URI like this:</p>
<source>
http://{host}:{port}/manager/{command}?{parameters}
</source>
<p>where <code>{host}</code> and <code>{port}</code> represent the hostname
and port number on which Tomcat is running, <code>{command}</code>
represents the Manager command you wish to execute, and
<code>{parameters}</code> represents the query parameters
that are specific to that command.  In the illustrations below, customize
the host and port appropriately for your installation.</p>

<p>Most commands accept one or more of the following query parameters:</p>
<ul>
<li><strong>path</strong> - The context path (including the leading slash)
    of the web application you are dealing with.  To select the ROOT web
    application, specify "/".  <strong>NOTE</strong> -
    It is not possible to perform administrative commands on the
    Manager application itself.</li>
<li><strong>war</strong> - 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:
    <ul>
    <li><strong>file:/absolute/path/to/a/directory</strong> - 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.</li>
    <li><strong>file:/absolute/path/to/a/webapp.war</strong> - The absolute
        path of a web application archive (WAR) file.  This is valid
        <strong>only</strong> for the <code>/deploy</code> command, and is
        the only acceptable format to that command.</li>
    <li><strong>jar:file:/absolute/path/to/a/warfile.war!/</strong> - The
        URL to a local web application archive (WAR) file.  You can use any
        syntax that is valid for the <code>JarURLConnection</code> class
        for reference to an entire JAR file.</li>
    <li><strong>file:/absolute/path/to/a/context.xml</strong> - The
        absolute path of a web application Context configuration ".xml"
        file which contains the Context configuration element.</li>
    <li><strong>directory</strong> - The directory name for the web
        application context in the Host's application base directory.</li>
    <li><strong>webapp.war</strong> - The name of a web application war file
        located in the Host's application base directory.</li>
    </ul></li>
</ul>

<p>Each command will return a response in <code>text/plain</code> 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
<code>OK</code> or <code>FAIL</code>, 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.</p>

<p><em>Internationalization Note</em> - 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.</p>

<blockquote><em>
<p><strong>WARNING:</strong>  the legacy commands <code>/install</code> and 
<code>/remove</code> are deprecated.
They are presently equivalent to <code>/deploy</code> and <code>/undeploy</code>,
but could be removed in a future release.</p>
</em></blockquote>

<subsection name="Deploy A New Application Remotely">

<source>
http://localhost:8080/manager/deploy
</source>

<p>Upload the web application archive (WAR) file that is specified as the
request data in this HTTP PUT request, install it into the <code>appBase</code>
directory of our corresponding virtual host, and start it using 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
<code>/undeploy</code>. To deploy the ROOT web application (the application
with a context path of "/"), name the war ROOT.war.</p>

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

<p>URL parameters include:
<ul>
<li><code>update</code>: When set to true, any existing update will be
    undeployed first. The default value is set to false.</li>
<li><code>tag</code>: Specifying a tag name, this allows associating the
    deployed webapp with a version number. The application version can
    be later redeployed when needed using only the tag.</li>
</ul>
</p>

<p><strong>NOTE</strong> - This command is the logical
opposite of the <code>/undeploy</code> command.</p>

<p>If installation and startup is successful, you will receive a response
like this:</p>
<source>
OK - Deployed application at context path /foo
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Application already exists at path /foo</em>
    <blockquote>
    <p>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 <code>update</code> parameter may be specified as
    a parameter on the URL, with a value of <code>true</code> to avoid this
    error. In that case, an undeploy will be performed on an existing
    application before performing the deployment.</p>
    </blockquote></li>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to start the new web application.
    Check the Tomcat 5 logs for the details, but likely explanations include
    problems parsing your <code>/WEB-INF/web.xml</code> file, or missing
    classes encountered when initializing application event listeners and
    filters.</p>
    </blockquote></li>
</ul>

</subsection>

<subsection name="Deploy A New Application from a Local Path">

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

<p>There are a number of different ways the deploy command can be used.</p>

<h3>Deploy a version of a previously deployed webapp</h3>

<p>This can be used to deploy a previous version of a web application, which
has been deployed using the <code>tag</code> attribute. Note that the work
directory for the manager webapp will contain the previously deployed WARs;
removing it would make the deployment fail.
<source>
http://localhost:8080/manager/deploy?path=/footoo&amp;tag=footag
</source>
</p>

<h3>Deploy a Directory or WAR by URL</h3>

<p>Deploy a web application directory or ".war" file located on the Tomcat
server. If no <code>path</code> is specified, the directory name or the war file
name without the ".war" extension is used as the path. The <code>war</code>
parameter specifies a URL (including the <code>file:</code> 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
<code>java.net.JarURLConnection</code> class.  Use only URLs that refer to
the entire WAR file.</p>

<p>In this example the web application located in the directory
<code>/path/to/foo</code> on the Tomcat server is deployed as the
web application context named <code>/footoo</code>.
<source>
http://localhost:8080/manager/deploy?path=/footoo&amp;war=file:/path/to/foo
</source>
</p>

<p>In this example the ".war" file <code>/path/to/bar.war</code> on the
Tomcat server is deployed as the web application context named
<code>/bar</code>. Notice that there is no <code>path</code> parameter
so the context path defaults to the name of the web application archive
file without the ".war" extension.
<source>
http://localhost:8080/manager/deploy?war=jar:file:/path/to/bar.war!/
</source>
</p>

<h3>Deploy a Directory or War from the Host appBase</h3>

<p>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.</p>

<p>In this example the web application located in a sub directory named
<code>foo</code> in the Host appBase directory of the Tomcat server is
deployed as the web application context named <code>/foo</code>. Notice
that the context path used is the name of the web application directory.
<source>
http://localhost:8080/manager/deploy?war=foo
</source>
</p>

<p>In this example the ".war" file <code>bar.war</code> located in your
Host appBase directory on the Tomcat server is deployed as the web
application context named <code>/bar</code>.
<source>
http://localhost:8080/manager/deploy?war=bar.war
</source>
</p>

<h3>Deploy using a Context configuration ".xml" file</h3>

<p>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 <code>path</code>
is not used when deploying a web application using a context ".xml"
configuration file.</p>

<p>A Context configuration ".xml" file can contain valid XML for a
web application Context just as if it were configured in your
Tomcat <code>server.xml</code> configuration file. Here is an
example:
<source>
&lt;Context path="/foobar" docBase="/path/to/application/foobar"
         debug="0"&gt;

  &lt;!-- Link to the user database we will get roles from --&gt;
  &lt;ResourceLink name="users" global="UserDatabase"
                type="org.apache.catalina.UserDatabase"/&gt;

&lt;/Context&gt;
</source>
</p>

<p>When the optional <code>war</code> 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.</p>

<p>Here is an example of deploying an application using a Context
configuration ".xml" file.
<source>
http://localhost:8080/manager/deploy?config=file:/path/context.xml
</source>
</p>

<p>Here is an example of deploying an application using a Context
configuration ".xml" file and a web application ".war" file located
on the server.
<source>
http://localhost:8080/manager/deploy?config=file:/path/context.xml&amp;war=file:/path/bar.war&amp;path=/bar
</source>
</p>

<h3>Deployment Notes</h3>

<p>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.</p>

<p>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.</p>

<p>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.</p>


<h3>Deploy Response</h3>

<p>If installation and startup is successful, you will receive a response
like this:</p>
<source>
OK - Deployed application at context path /foo
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Application already exists at path /foo</em>
    <blockquote>
    <p>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 <code>update</code> parameter may be specified as
    a parameter on the URL, with a value of <code>true</code> to avoid this
    error. In that case, an undeploy will be performed on an existing
    application before performing the deployment.</p>
    </blockquote></li>
<li><em>Document base does not exist or is not a readable directory</em>
    <blockquote>
    <p>The URL specified by the <code>war</code> 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 <code>war</code> parameter.</p>
    </blockquote></li>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to start the new web application.
    Check the Tomcat 5 logs for the details, but likely explanations include
    problems parsing your <code>/WEB-INF/web.xml</code> file, or missing
    classes encountered when initializing application event listeners and
    filters.</p>
    </blockquote></li>
<li><em>Invalid application URL was specified</em>
    <blockquote>
    <p>The URL for the directory or web application that you specified
    was not valid.  Such URLs must start with <code>file:</code>, and URLs
    for a WAR file must end in ".war".</p>
    </blockquote></li>
<li><em>Invalid context path was specified</em>
    <blockquote>
    <p>The context path must start with a slash character. To reference the
    ROOT web application use "/".</p>
    </blockquote></li>
<li><em>Context path must match the directory or WAR file name:</em>
    <blockquote>
    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.
    </blockquote></li>
<li><em>Only web applications in the Host web application directory can
     be installed</em>
     <blockquote>
     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.
     </blockquote></li>
</ul>

</subsection>

<subsection name="List Currently Deployed Applications">

<source>
http://localhost:8080/manager/list
</source>

<p>List the context paths, current status (<code>running</code> or
<code>stopped</code>), and number of active sessions for all currently
deployed web applications.  A typical response immediately
after starting Tomcat might look like this:</p>
<source>
OK - Listed applications for virtual host localhost
/webdav:running:0
/examples:running:0
/manager:running:0
/:running:0
</source>

</subsection>

<subsection name="Reload An Existing Application">

<source>
http://localhost:8080/manager/reload?path=/examples
</source>

<p>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 <code>/WEB-INF/classes</code>
directory or when you have added or updated jar files in the
<code>/WEB-INF/lib</code> directory.
</p>
<p><strong>NOTE:</strong> The <code>/WEB-INF/web.xml</code>
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.
</p>

<p>If this command succeeds, you will see a response like this:</p>
<source>
OK - Reloaded application at context path /examples
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to restart the web application.
    Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
<li><em>Invalid context path was specified</em>
    <blockquote>
    <p>The context path must start with a slash character. To reference the
    ROOT web application use "/".</p>
    </blockquote></li>
<li><em>No context exists for path /foo</em>
    <blockquote>
    <p>There is no deployed application on the context path
    that you specified.</p>
    </blockquote></li>
<li><em>No context path was specified</em>
    <blockquote>
    The <code>path</code> parameter is required.
    </blockquote></li>
<li><em>Reload not supported on WAR deployed at path /foo</em>
    <blockquote>
    Currently, application reloading (to pick up changes to the classes or
    <code>web.xml</code> 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 <code>undeploy</code> and then <code>deploy</code> or
    <code>deploy</code> with the <code>update</code> parameter the
    application again to pick up your changes.
    </blockquote></li>
</ul>

</subsection>

<subsection name="List OS and JVM Properties">

<source>
http://localhost:8080/manager/serverinfo
</source>

<p>Lists information about the Tomcat version, OS, and JVM properties.</p>

<p>If an error occurs, the response will start with <code>FAIL</code> and
include an error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to enumerate the system properties.
    Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
</ul>

</subsection>

<subsection name="List Available Global JNDI Resources">

<source>
http://localhost:8080/manager/resources[?type=xxxxx]
</source>

<p>List the global JNDI resources that are available for use in resource
links for context configuration files.  If you specify the <code>type</code>
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
<code>javax.sql.DataSource</code> to acquire the names of all available
JDBC data sources).  If you do not specify the <code>type</code> request
parameter, resources of all types will be returned.</p>

<p>Depending on whether the <code>type</code> request parameter is specified
or not, the first line of a normal response will be:</p>
<pre>
  OK - Listed global resources of all types
</pre>
<p>or</p>
<pre>
  OK - Listed global resources of type xxxxx
</pre>
<p>followed by one line for each resource.  Each line is composed of fields
delimited by colon characters (":"), as follows:</p>
<ul>
<li><em>Global Resource Name</em> - The name of this global JNDI resource,
    which would be used in the <code>global</code> attribute of a
    <code>&lt;ResourceLink&gt;</code> element.</li>
<li><em>Global Resource Type</em> - The fully qualified Java class name of
    this global JNDI resource.</li>
</ul>

<p>If an error occurs, the response will start with <code>FAIL</code> and
include an error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to enumerate the global JNDI
    resources.  Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
<li><em>No global JNDI resources are available</em>
    <blockquote>
    <p>The Tomcat server you are running has been configured without
    global JNDI resources.</p>
    </blockquote></li>
</ul>


</subsection>


<subsection name="List Available Security Roles">

<source>
http://localhost:8080/manager/roles
</source>

<p>List the security role names (and corresponding descriptions) that are
available in the <code>org.apache.catalina.UserDatabase</code> resource that
is linked to the <code>users</code> 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
<code>&lt;security-role-ref&gt;</code> elements to map security role names
used in a web application to the role names actually defined within the
container.</p>

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

<p>When this command is executed, the first line of the response will be:</p>
<pre>
  OK - Listed security roles
</pre>
<p>followed by one line for each security role.  Each line is composed of
fields delimited by colon characters (":") as follows:</p>
<ul>
<li><em>Security Role Name</em> - A security role name that is known to Tomcat
    in the user database.</li>
<li><em>Description</em> - Description of this security role (useful in
    creating user interfaces for selecting roles.</li>
</ul>

<p>If an error occurs, the response will start with <code>FAIL</code> and
include an error message.  Possible causes for problems include:</p>
<ul>
<li><em>Cannot resolve user database reference</em> - A JNDI error prevented
    the successful lookup of the <code>org.apache.catalina.UserDatabase</code>
    resource.  Check the Tomcat log files for a stack trace associated with
    this error.</li>
<li><em>No user database is available</em> - You have not configured a resource
    reference for the <code>users</code> resource that points at an
    appropriate user database instance.  Check your <code>manager.xml</code>
    file and ensure that you have created an appropriate
    <code>&lt;ResourceLink&gt;</code> or
    <code>&lt;ResourceParams&gt;</code> element for this resource.</li>
</ul>

</subsection>


<subsection name="Session Statistics">

<source>
http://localhost:8080/manager/sessions?path=/examples
</source>

<p>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 <code>/examples</code> web app,
you might get something like this:</p>
<source>
OK - Session information for application at context path /examples
Default maximum session inactive interval 30 minutes
30 - &lt;40 minutes:1 sessions
</source>

</subsection>


<subsection name="Start an Existing Application">

<source>
http://localhost:8080/manager/start?path=/examples
</source>

<p>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.</p>

<p>If this command succeeds, you will see a response like this:</p>
<source>
OK - Started application at context path /examples
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to start the web application.
    Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
<li><em>Invalid context path was specified</em>
    <blockquote>
    <p>The context path must start with a slash character. To reference the
    ROOT web application use "/".</p>
    </blockquote></li>
<li><em>No context exists for path /foo</em>
    <blockquote>
    <p>There is no deployed application on the context path
    that you specified.</p>
    </blockquote></li>
<li><em>No context path was specified</em>
    <blockquote>
    The <code>path</code> parameter is required.
    </blockquote></li>
</ul>

</subsection>

<subsection name="Stop an Existing Application">

<source>
http://localhost:8080/manager/stop?path=/examples
</source>

<p>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.</p>

<p>If this command succeeds, you will see a response like this:</p>
<source>
OK - Stopped application at context path /examples
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to stop the web application.
    Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
<li><em>Invalid context path was specified</em>
    <blockquote>
    <p>The context path must start with a slash character. To reference the
    ROOT web application use "/".</p>
    </blockquote></li>
<li><em>No context exists for path /foo</em>
    <blockquote>
    <p>There is no deployed application on the context path
    that you specified.</p>
    </blockquote></li>
<li><em>No context path was specified</em>
    <blockquote>
    The <code>path</code> parameter is required.
    </blockquote></li>
</ul>

</subsection>


<subsection name="Undeploy an Existing Application">

<source>
http://localhost:8080/manager/undeploy?path=/examples
</source>

<p><strong><font color="red">WARNING</font> - This command will delete any web 
application artifacts that exist within <code>appBase</code> directory 
(typically "webapps") for this virtual host</strong>.
This will delete the 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
<code>$CATALINA_HOME/conf/[enginename]/[hostname]/</code> directory. 
If you simply want to take an application
out of service, you should use the <code>/stop</code> command instead.</p>

<p>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 <code>appBase</code> directory (typically "webapps") for
this virtual host.  This command is the logical opposite of the
<code>/deploy</code> command.</p>

<p>If this command succeeds, you will see a response like this:</p>
<source>
OK - Undeployed application at context path /examples
</source>

<p>Otherwise, the response will start with <code>FAIL</code> and include an
error message.  Possible causes for problems include:</p>
<ul>
<li><em>Encountered exception</em>
    <blockquote>
    <p>An exception was encountered trying to undeploy the web application.
    Check the Tomcat 5 logs for the details.</p>
    </blockquote></li>
<li><em>Invalid context path was specified</em>
    <blockquote>
    <p>The context path must start with a slash character. To reference the
    ROOT web application use "/".</p>
    </blockquote></li>
<li><em>No context exists for path /foo</em>
    <blockquote>
    <p>There is no deployed application on the context path
    that you specified.</p>
    </blockquote></li>
<li><em>No context path was specified</em>
    <blockquote>
    The <code>path</code> parameter is required.
    </blockquote></li>
</ul>

</subsection>

</section>

<section name="Executing Manager Commands With Ant">

<p>In addition to the ability to execute Manager commands via HTTP requests,
as documented above, Tomcat 5 includes a convenient set of Task definitions
for the <em>Ant</em> (version 1.4 or later) build tool.  In order to use these
commands, you must perform the following setup operations:</p>
<ul>
<li>Download the binary distribution of Ant from
    <a href="http://ant.apache.org">http://ant.apache.org</a>.
    You must use version <strong>1.4</strong> or later.</li>
<li>Install the Ant distribution in a convenient directory (called
    ANT_HOME in the remainder of these instructions).</li>
<li>Copy the file <code>server/lib/catalina-ant.jar</code> from your Tomcat 5
    installation into Ant's library directory (<code>$ANT_HOME/lib</code>).
    </li>
<li>Add the <code>$ANT_HOME/bin</code> directory to your <code>PATH</code>
    environment variable.</li>
<li>Configure at least one username/password combination in your Tomcat
    user database that includes the <code>manager</code> role.</li>
</ul>

<p>To use custom tasks within Ant, you must declare them first with a
<code>&lt;taskdef&gt;</code> element.  Therefore, your <code>build.xml</code>
file might look something like this:</p>

<table border="1">
<tr><td><pre>
&lt;project name="My Application" default="compile" basedir="."&gt;

  &lt;!-- Configure the directory into which the web application is built --&gt;
  &lt;property name="build"    value="${basedir}/build"/&gt;

  &lt;!-- Configure the context path for this application --&gt;
  &lt;property name="path"     value="/myapp"/&gt;

  &lt;!-- Configure properties to access the Manager application --&gt;
  &lt;property name="url"      value="http://localhost:8080/manager"/&gt;
  &lt;property name="username" value="myusername"/&gt;
  &lt;property name="password" value="mypassword"/&gt;

  &lt;!-- Configure the custom Ant tasks for the Manager application --&gt;
  &lt;taskdef name="deploy"    classname="org.apache.catalina.ant.DeployTask"/&gt;
  &lt;taskdef name="list"      classname="org.apache.catalina.ant.ListTask"/&gt;
  &lt;taskdef name="reload"    classname="org.apache.catalina.ant.ReloadTask"/&gt;
  &lt;taskdef name="resources" classname="org.apache.catalina.ant.ResourcesTask"/&gt;
  &lt;taskdef name="roles"     classname="org.apache.catalina.ant.RolesTask"/&gt;
  &lt;taskdef name="start"     classname="org.apache.catalina.ant.StartTask"/&gt;
  &lt;taskdef name="stop"      classname="org.apache.catalina.ant.StopTask"/&gt;
  &lt;taskdef name="undeploy"  classname="org.apache.catalina.ant.UndeployTask"/&gt;

  &lt;!-- Executable Targets --&gt;
  &lt;target name="compile" description="Compile web application"&gt;
    &lt;!-- ... construct web application in ${build} subdirectory, and
            generated a ${path}.war ... --&gt;
  &lt;/target&gt;

  &lt;target name="deploy" description="Install web application"
          depends="compile"&gt;
    &lt;deploy url="${url}" username="${username}" password="${password}"
            path="${path}" war="file:${build}${path}.war"/&gt;
  &lt;/target&gt;

  &lt;target name="reload" description="Reload web application"
          depends="compile"&gt;
    &lt;reload  url="${url}" username="${username}" password="${password}"
            path="${path}"/&gt;
  &lt;/target&gt;

  &lt;target name="undeploy" description="Remove web application"&gt;
    &lt;undeploy url="${url}" username="${username}" password="${password}"
            path="${path}"/&gt;
  &lt;/target&gt;

&lt;/project&gt;
</pre></td></tr>
</table>

<p>Now, you can execute commands like <code>ant deploy</code> to deploy the
application to a running instance of Tomcat, or <code>ant reload</code> to
tell Tomcat to reload it.  Note also that most of the interesting values in
this <code>build.xml</code> 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
<code>build.xml</code> file's source code.  To avoid this, omit the password
property, and specify it from the command line:</p>
<pre>
  ant -Dpassword=secret deploy
</pre>

<subsection name="Tasks output capture">

<p>Using <em>Ant</em> version <strong>1.6.2</strong> 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 
<code>&lt;redirector&gt;</code> type attributes:
</p>

<table border="1" cellpadding="2" cellspacing="0">
<tbody>
<tr>
<td valign="top"><b>Attribute</b></td>
<td valign="top"><b>Description</b></td>
<td align="center" valign="top"><b>Required</b></td>
</tr>
<tr>
<td valign="top">output</td>
<td valign="top">Name of a file to which to write the output. If
the error stream is not also redirected to a file or property, it will
appear in this output.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">error</td>
<td valign="top">The file to which the standard error of the
command should be redirected.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">logError</td>
<td valign="top">This attribute is used when you wish to see
error output in Ant's log and you are redirecting output to a
file/property. The error output will not be included in the output
file/property. If you redirect error with the <i>error</i> or <i>errorProperty</i>
attributes, this will have no effect.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">append</td>
<td valign="top">Whether output and error files should be
appended to or overwritten. Defaults to <code>false</code>.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">createemptyfiles</td>
<td valign="top">Whether output and error files should be created
even when empty. Defaults to <code>true</code>.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">outputproperty</td>
<td valign="top">The name of a property in which the output of
the command should be stored. Unless the error stream is redirected to
a separate file or stream, this property will include the error output.</td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">errorproperty</td>
<td valign="top">The name of a property in which the standard
error of the command should be stored.</td>
<td align="center" valign="top">No</td>
</tr>
</tbody>
</table>

<p>A couple of additional attributes can also be specified:
</p>
<table border="1" cellpadding="2" cellspacing="0">
<tbody>
<tr>
<td valign="top"><b>Attribute</b></td>
<td valign="top"><b>Description</b></td>
<td align="center" valign="top"><b>Required</b></td>
</tr>
<tr>
<td valign="top">alwaysLog</td>
<td valign="top">This attribute is used when you wish to see the
output you are capturing, appearing also in the Ant's log. It must not be
used unless you are capturing task output.
Defaults to <code>false</code>.
<em>This attribute will be supported directly by <code>&lt;redirector&gt;</code>
in Ant 1.6.3</em></td>
<td align="center" valign="top">No</td>
</tr>
<tr>
<td valign="top">failonerror</td>
<td valign="top">This attribute is used when you wish to avoid that
any manager command processing error terminates the ant execution. Defaults to <code>true</code>.
It must be set to <code>false</code>, if you want to capture error output,
otherwise execution will terminate before anything can be captured.
<br></br>
This attribute acts only on manager command execution,
any wrong or missing command attribute will still cause Ant execution termination.
</td>
<td align="center" valign="top">No</td>
</tr>
</tbody>
</table>

<p>They also support the embedded <code>&lt;redirector&gt;</code> element
in which you can specify
its full set of attributes, but <code>input</code>, <code>inputstring</code> and 
<code>inputencoding</code> that, even if accepted, are not used because they have
no meaning in this context.
Refer to <a href="http://ant.apache.org">ant manual</a> for details on 
<code>&lt;redirector&gt;</code> element attributes.
</p>

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

<table border="1">
<tr><td><pre>
	&lt;target name="manager.deploy"
		depends="context.status"
		if="context.notInstalled"&gt;
		&lt;deploy url="${mgr.url}"
			username="${mgr.username}"
			password="${mgr.password}"
			path="${mgr.context.path}"
			config="${mgr.context.descriptor}"/&gt;
	&lt;/target&gt;

	&lt;target name="manager.deploy.war"
		depends="context.status"
		if="context.deployable"&gt;
		&lt;deploy url="${mgr.url}"
			username="${mgr.username}"
			password="${mgr.password}"
			update="${mgr.update}"
			path="${mgr.context.path}"
			war="${mgr.war.file}"/&gt;
	&lt;/target&gt;
	
	&lt;target name="context.status"&gt;
		&lt;property name="running" value="${mgr.context.path}:running"/&gt;
		&lt;property name="stopped" value="${mgr.context.path}:stopped"/&gt;
	
		&lt;list url="${mgr.url}"
			outputproperty="ctx.status"
			username="${mgr.username}"
			password="${mgr.password}"&gt;
		&lt;/list&gt;
		
		&lt;condition property="context.running"&gt;
			&lt;contains string="${ctx.status}" substring="${running}"/&gt;
		&lt;/condition&gt;
		&lt;condition property="context.stopped"&gt;
			&lt;contains string="${ctx.status}" substring="${stopped}"/&gt;
		&lt;/condition&gt;
		&lt;condition property="context.notInstalled"&gt;
			&lt;and&gt;
				&lt;isfalse value="${context.running}"/&gt;
				&lt;isfalse value="${context.stopped}"/&gt;
			&lt;/and&gt;
		&lt;/condition&gt;
		&lt;condition property="context.deployable"&gt;
			&lt;or&gt;
				&lt;istrue value="${context.notInstalled}"/&gt;
				&lt;and&gt;
					&lt;istrue value="${context.running}"/&gt;
					&lt;istrue value="${mgr.update}"/&gt;
				&lt;/and&gt;
				&lt;and&gt;
					&lt;istrue value="${context.stopped}"/&gt;
					&lt;istrue value="${mgr.update}"/&gt;
				&lt;/and&gt;
			&lt;/or&gt;
		&lt;/condition&gt;
		&lt;condition property="context.undeployable"&gt;
			&lt;or&gt;
				&lt;istrue value="${context.running}"/&gt;
				&lt;istrue value="${context.stopped}"/&gt;
			&lt;/or&gt;
		&lt;/condition&gt;
	&lt;/target&gt;
</pre></td></tr>
</table>

<p><strong>WARNING:</strong> 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:
<ul>
<li>when capturing in a property you will find in it only the output from the <em>first</em> call, because
Ant properties are immutable and once set they cannot be changed,
</li>
<li>when capturing in a file, each run will overwrite it and you will find in it only the <em>last</em> call
output, unless you are using the <code>append="true"</code> attribute, in which case you will
see the output of each task call appended to the file.
</li>
</ul>
</p>

</subsection>

</section>

<section name="Using the JMX Proxy Servlet">

  <subsection name="What is JMX Proxy Servlet">
    The JMX Proxy Servlet is a lightweight proxy to get and set the
    tomcat internals. (Or any class that has been exposed via an MBean)
    Its usage is not very user friendly but the UI is
    extremely help for integrating command line scripts for monitoring
    and changing the internals of tomcat. You can do two things with the proxy:
    get information and set information. For you to really understand the
    JMX Proxy Servlet, you should have a general understanding of JMX.
    If you don't know what JMX is, then prepare to be confused.
  </subsection>

  <subsection name="JMX Query command">
    This takes the form:
<source>
http://webserver/manager/jmxproxy/?qry=STUFF
</source>
    Where <code>STUFF</code> is the JMX query you wish to perform. For example,
    here are some queries you might wish to run:
    <ul>
      <li>
        <code>qry=*%3Atype%3DRequestProcessor%2C* -->
         type=RequestProcessor</code> which will locate all
         workers which can process requests and report
         their state.
      </li>
      <li>
        <code>qry=*%3Aj2eeType=Servlet%2c* -->
            j2eeType=Servlet</code> which return all loaded servlets.
      </li>
      <li>
        <code>qry=Catalina%3Atype%3DEnvironment%2Cresourcetype%3DGlobal%2Cname%3DsimpleValue -->
            Catalina:type=Environment,resourcetype=Global,name=simpleValue</code>
            which look for a specific MBean by the given name.
      </li>
    </ul>
    You'll need to experiment with this to really understand its capabilites.
    If you provide no <code>qry</code> 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.
  </subsection>

  <subsection name="JMX Set command">
    Now that you can query an MBean, its time to muck with Tomcat's internals!
    The general form of the set command is :
<source>
http://webserver/manager/jmxproxy/?set=BEANNAME&amp;att=MYATTRIBUTE&amp;val=NEWVALUE
</source>
    So you need to provide 3 request parameters:
    <ol>
      <li><code>set</code>: The full bean name</li>
      <li><code>att</code>: The attribute you wish to alter</li>
      <li><code>val</code>: The new value </li>
    </ol>
    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
    <code>ErrorReportValve</code>. The following will set debugging to 10.
<source>
http://localhost:8080/manager/jmxproxy/
?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost&amp;att=debug&amp;val=10
</source>
    and my result is (YMMV):
<source>
Result: ok
</source>

    Here is what I see if I pass in a bad value. Here is the URL I used,
    I try set debugging equal to 'cowbell':
<source>
http://localhost:8080/manager/jmxproxy/
?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost&amp;att=debug&amp;val=cowbell
</source>
    When I try that, my result is
<source>
Error: java.lang.NumberFormatException: For input string: "cowbell"
</source>
  </subsection>


</section>



</body>

</document>
