介绍
在许多生产环境中，能够部署新的 Web 应用程序或取消部署现有应用程序， 而不必关闭并重新启动整个容器，这非常有用。 此外，可以请求现有应用程序重新加载自身， 即使尚未在 Tomcat 服务器配置文件中声明它可`重新加载`。
为了支持这些功能，Tomcat 包括一个 Web 应用程序（默认安装在上下文路径 /manager 上），该应用程序支持以下功能：
-
从上传的 WAR 文件内容部署新的 Web 应用程序。
-
从服务器文件系统在指定的上下文路径上部署新的 Web 应用程序。
-
列出当前部署的 Web 应用程序，以及当前为这些 Web 应用程序活动的会话。
-
重新加载现有 Web 应用程序，以反映
/WEB-INF/classes或/WEB-INF/lib内容中的更改。 -
列出 OS 和 JVM 属性值。
-
列出可用的全局 JNDI 资源，以便在准备
<ResourceLink>嵌套在部署描述中的元素的部署工具中使用<Context>。 -
启动已停止的应用程序（从而使其再次可用）。
-
停止现有应用程序（使其变得不可用），但不要取消部署它。
-
取消部署已部署的 Web 应用程序并删除其文档基目录（除非它是从文件系统部署的）。
默认 Tomcat 安装包括为默认虚拟主机配置的 Manager 应用程序实例。
如果创建其他虚拟主机，则可能需要将 Manager 应用程序的实例添加到其中的一个或多个主机。
要将 Manager Web 应用程序上下文的实例添加到新主机，
请在 $CATALINA_BASE/conf/[enginename]/[hostname] 文件夹中安装 manager.xml 上下文配置文件。
下面是一个示例：
<Context privileged="true" antiResourceLocking="false"
docBase="${catalina.home}/webapps/manager">
<CookieProcessor className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
sameSiteCookies="strict" />
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
<Manager sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
</Context>有三种方法可以使用 Manager Web 应用程序。
-
作为具有在浏览器中使用的用户界面的应用程序。下面是一个示例 URL，可以在其中将
localhost替换为网站主机名：http://localhost:8080/manager/html。 -
仅使用 HTTP 请求的最低版本，适合系统管理员设置的脚本使用。命令作为请求 URI 的一部分提供，响应采用简单文本的形式，可以轻松解析和处理。有关更多信息，请参阅支持的 Manager 命令。
-
Ant（版本 1.4 或更高版本）构建工具的一组方便的任务定义。有关更多信息，请参阅使用 Ant 执行 Manager 命令。
配置 Manager 应用程序访问
下面的描述使用变量名称 $CATALINA_BASE 来引用解析大多数相对路径所依据的基目录。 如果没有通过设置 CATALINA_BASE 目录为多个实例配置 Tomcat， 则 $CATALINA_BASE 将设置为 $CATALINA_HOME 的值，即安装 Tomcat 的目录。
如果 Tomcat 的默认设置允许 Internet 上的任何人在服务器上执行 Manager 应用程序，
那么 Tomcat 将是非常不安全的。因此，Manager 应用程序附带了一项要求，
即任何尝试使用它的人都必须使用具有与其关联的 manager-xxx 角色之一的用户名和密码
（角色名称取决于所需的功能）对自己进行身份验证。
此外，默认用户文件（$CATALINA_BASE/conf/tomcat-users.xml）中没有分配给这些角色的用户名。
因此，默认情况下，对 Manager 应用程序的访问是完全禁用的。
可以在 Manager Web 应用程序的 web.xml 文件中找到角色名称。
可用的角色包括：
-
manager-gui — 访问 HTML 界面。
-
manager-status — 仅访问“Server Status”页面。
-
manager-script — 访问本文档中描述的工具友好型纯文本界面和“Server Status”页面。
-
manager-jmx — 访问 JMX 代理界面和“服务器状态”页面。
HTML 接口受到保护，可抵御 CSRF（跨站点请求伪造）攻击，但无法保护文本和 JMX 接口。 这意味着，允许访问文本和 JMX 界面的用户在使用 Web 浏览器访问 Manager 应用程序时必须小心。 要维护 CSRF 保护：
-
如果使用具有 manager-script 或 manager-jmx 角色 （例如，用于测试纯文本或 JMX 界面）的用户使用 Web 浏览器访问 Manager 应用程序， 则必须在之后关闭浏览器的所有窗口以终止会话。 如果不关闭浏览器并访问其他站点，可能会成为 CSRF 攻击的受害者。
-
建议永远不要将 manager-script 或 manager-jmx 角色授予具有 manager-gui 角色的用户。
请注意，JMX 代理接口实际上是 Tomcat 的低级类似 root 的管理接口。 如果知道要调用什么命令，就可以做很多事情。启用 manager-jmx 角色时应谨慎。
要启用对 Manager Web 应用程序的访问，必须创建一个新的用户名/密码组合 并将其中一个 manager-xxx 角色与其关联， 或者将 manager-xxx 角色添加到某个现有的用户名/密码组合中。 由于本文档的大部分内容描述了如何使用文本界面， 因此此示例将使用角色名称 manager-script。 用户名 / 密码的配置方式取决于使用的 Realm 实现：
-
UserDatabaseRealm 加上 MemoryUserDatabase 或 MemoryRealm — UserDatabaseRealm 和 MemoryUserDatabase 在默认的
$CATALINA_BASE/conf/server.xml中配置。默认情况下，MemoryUserDatabase 和 MemoryRealm 都会读取存储在$CATALINA_BASE/conf/tomcat-users.xml的 XML 格式文件，该文件可以使用任何文本编辑器进行编辑。此文件包含`<user>`每个用户的 XML，可能如下所示：
<user username="craigmcc" password="secret" roles="standard,manager-script" />定义此个人用于登录的用户名和密码，以及它们关联的角色名称。可以将 manager-script 角色添加到一个或多个现有用户的逗号分隔 roles 属性中，和/或使用该分配的角色创建新用户。 * DataSourceRealm – 用户和角色信息存储在通过 JDBC 访问的数据库中。将 manager-script 角色添加到一个或多个现有用户，和/或按照环境的标准过程创建一个或多个分配了此角色的新用户。 * JNDIRealm — 用户和角色信息存储在通过 LDAP 访问的目录服务器中。将 manager-script 角色添加到一个或多个现有用户，和/或按照环境的标准过程创建一个或多个分配了此角色的新用户。
首次尝试发出下一节中描述的 Manager 命令之一时，将要求使用 BASIC 身份验证登录。 输入的用户名和密码无关紧要，只要它们在 users 数据库中标识拥有角色 manager-script 的有效用户即可。
除了密码限制之外，远程 IP 地址或主机还可以通过添加
RemoteAddrValve 或 RemoteHostValve 来限制对 Manager Web 应用程序的访问。
有关详细信息，请参阅 valves 文档。
以下是按 IP 地址限制对 localhost 的访问的示例：
<Context privileged="true">
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1"/>
</Context>HTML 用户友好的界面
管理 Web 应用程序的用户友好型 HTML 界面位于
如上所述，需要 manager-gui 角色才能访问它。 有一个单独的文档提供有关此界面的帮助：
HTML 界面受到保护，可抵御 CSRF（跨站点请求伪造）攻击。 每次访问 HTML 页面都会生成一个随机令牌， 该令牌存储在会话中，并包含在页面上的所有链接中。 如果下一个操作没有正确的令牌值，则该操作将被拒绝。 如果令牌已过期，可以从 Manager 的主页或列出应用程序页面重新开始。
要自定义 Manager Web 应用程序的 HTML 界面的副标题，
可以将任何有效的 xml 转义 html 代码添加到
HTMLManagerServlet 的 htmlSubTitle 初始化参数中
<servlet>
<servlet-name>HTMLManager</servlet-name>
<servlet-class>org.apache.catalina.manager.HTMLManagerServlet</servlet-class>
<init-param>
<param-name>htmlSubTitle</param-name>
<param-value>Company Inc.<br><i style='color:red'>Staging</i></param-value>
</init-param>
...
</servlet>上述字符串值将取消转义并附加到标题
Company Inc.<br><i style='color:red'>Staging</i>
支持的 Manager 命令
Manager 应用程序知道如何处理的所有命令都在单个请求 URI 中指定， 如下所示：
其中 {host} 和 {port} 表示运行 Tomcat 的主机名和端口号，
{command} 表示要执行的 Manager 命令，
{parameters} 表示特定于该命令的查询参数。
在下面，自定义主机和端口。
这些命令通常由 HTTP GET 请求执行。
/deploy 命令具有由 HTTP PUT 请求执行的表单。
通用参数
大多数命令接受以下一个或多个查询参数：
-
path - 正在处理的 Web 应用程序的上下文路径（包括前导斜杠）。要选择 ROOT Web 应用程序，请指定 “/”。 注意：无法对 Manager 应用程序本身执行管理命令。 注意：如果未明确指定 path 参数，则将使用标准 Context 命名规则从 config 参数派生路径和版本，如果 config 参数不存在，则使用 war 参数派生。
-
version - 并行部署功能使用的此 Web 应用程序的版本。 如果在需要路径的地方使用并行部署，则除了路径之外，还必须指定一个版本， 并且路径和版本的组合必须是唯一的，而不仅仅是路径。 注意：如果未明确指定路径，则忽略 version 参数。
-
war - Web 应用程序存档 （WAR） 文件的 URL，或包含 Web 应用程序的目录的路径名，或上下文配置 “.xml” 文件。可以使用以下任何格式的 URL：
-
file：/absolute/path/to/a/directory - 包含 Web 应用程序的解压缩版本的目录的绝对路径。此目录将附加到您指定的上下文路径，无需任何更改。
-
file：/absolute/path/to/a/webapp.war - Web 应用程序存档 （WAR） 文件的绝对路径。这仅对 /deploy 命令有效，并且是该命令唯一可接受的格式。
-
file：/absolute/path/to/a/context.xml - 包含 Context 配置元素的 Web 应用程序上下文配置 “.xml” 文件的绝对路径。
-
directory - Host 的应用程序基目录中 Web 应用程序上下文的目录名称。
-
webapp.war - 位于 Host 的应用程序基目录中的 Web 应用程序 war 文件的名称。
-
每个命令都将以文本/纯格式（即没有 HTML 标记的纯 ASCII ）返回响应， 使人类和程序都易于阅读。响应的第一行将以 OK 或 FAIL 开头， 指示请求的命令是否成功。如果失败，第一行的其余部分将包含所遇到问题的描述。 某些命令包括如下所述的附加信息行。
国际化标注 - Manager 应用程序在资源包中查找其消息字符串，因此这些字符串可能已针对平台进行了翻译。以下示例显示了消息的英文版本。
远程部署新的应用程序存档 （WAR）
上传在此 HTTP PUT 请求中指定为请求数据的 Web 应用程序存档 （WAR） 文件，
将其安装到相应虚拟主机的 appBase 目录中，然后启动，
从指定路径派生添加到 appBase 的 WAR 文件的名称。
稍后可以使用 /undeploy 命令取消部署应用程序（并删除相应的 WAR 文件）。
此命令由 HTTP PUT 请求执行。
WAR 文件可以通过在 /META-INF/context.xml 中包含上下文配置 XML 文件来包含 Tomcat 特定的部署配置。
URL 参数包括：
-
update：设置为 true 时，将首先取消部署任何现有更新。默认值设置为 false。
-
tag：指定标签名称，这允许将部署的 Web 应用程序与标签或标签相关联。如果 Web 应用程序已取消部署，则稍后可以在需要时仅使用标记重新部署它。
-
config ：上下文配置“.xml”文件的 URL，格式为
file：/absolute/path/to/a/context.xml。这必须是包含 Context 配置元素的 Web 应用程序上下文配置 “.xml” 文件的绝对路径。
注意 - 此命令在逻辑上与 /undeploy 命令相反。
如果安装和启动成功，将收到如下响应：
OK - Deployed application at context path /foo
否则，响应将以 FAIL 开头并包含错误消息。 问题的可能原因包括：
-
应用程序已存在于路径 /foo 中
当前正在运行的所有 Web 应用程序的上下文路径必须是唯一的。
因此，必须使用此上下文路径取消部署现有 Web 应用程序，
或者为新 Web 应用程序选择不同的上下文路径。
可以将 update 参数指定为 URL 上的参数，其值为 true 以避免此错误。
在这种情况下，在执行部署之前，将对现有应用程序执行取消部署。
-
遇到异常
尝试启动新的 Web 应用程序时遇到异常。
有关详细信息，请查看 Tomcat 日志，
但可能的原因包括解析 /WEB-INF/web.xml 文件时出现问题，
或在初始化应用程序事件侦听器和筛选器时遇到缺少类。
从本地路径部署新应用程序
部署并启动一个新的 Web 应用程序，
该应用程序附加到指定的上下文`路径`（该路径不得被任何其他 Web 应用程序使用）。
此命令在逻辑上与 /undeploy 命令相反。
此命令由 HTTP GET 请求执行。 deploy 命令有多种不同的使用方式。
部署以前部署的 Web 应用程序
这可用于部署以前部署的 Web 应用程序，
该应用程序已使用 tag 属性进行部署。
请注意，Manager Web 应用程序的工作目录将包含之前部署的 WAR;
删除它会导致部署失败。
通过 URL 部署目录或 WAR
部署位于 Tomcat 服务器上的 Web 应用程序目录或“.war”文件。
如果未指定 path，则 path 和 version 将从目录名称或 war 文件名派生。
war 参数指定目录或 Web 应用程序存档 （WAR） 文件的 URL（包括 file： scheme）。
java.net.JarURLConnection 类的 Javadocs 页面上介绍了引用 WAR 文件的 URL 支持的语法。
仅使用引用整个 WAR 文件的 URL。
在此示例中，位于 Tomcat 服务器上目录 /path/to/foo 中的
Web 应用程序被部署为名为 /footoo 的 Web 应用程序上下文。
在此示例中，Tomcat 服务器上的 “.war” 文件 /path/to/bar.war
被部署为名为 /bar 的 Web 应用程序上下文。
请注意，没有 path 参数，因此上下文路径默认为
不带 “.war” 扩展名的 Web 应用程序存档文件的名称。
从主机 appBase 部署 Directory 或 War
部署位于 Host appBase 目录中的 Web 应用程序目录或“.war”文件。 path 和可选 version 派生自 directory 或 war 文件名。
在此示例中，位于 Tomcat 服务器的 Host appBase 目录中名为 foo 的子目录中的
Web 应用程序被部署为名为 /foo 的 Web 应用程序上下文。
请注意，使用的上下文路径是 Web 应用程序目录的名称。
在此示例中，位于 Tomcat 服务器上 Host appBase 目录中的
“.war” 文件 bar.war 被部署为名为 /bar 的 Web 应用程序上下文。
使用 Context 配置 “.xml” 文件进行部署
如果 Host deployXML 标志设置为 true，则可以使用上下文配置 “.xml” 文件 和可选的 “.war” 文件或 Web 应用程序目录来部署 Web 应用程序。 使用上下文 “.xml” 配置文件部署 Web 应用程序时，不使用上下文路径。
Context 配置 “.xml” 文件可以包含 Web 应用程序 Context 的有效 XML， 就像在 Tomcat `server.xml`配置文件中配置一样。下面是一个示例：
<Context path="/foobar" docBase="/path/to/application/foobar">
</Context>当可选的 war 参数设置为 Web 应用程序 “.war” 文件或目录的 URL 时，
将覆盖上下文配置 “.xml” 文件中配置的任何 docBase。
以下是使用 Context 配置 “.xml” 文件部署应用程序的示例。
以下是使用位于服务器上的上下文配置 “.xml” 文件和 Web 应用程序 “.war” 文件部署应用程序的示例。
部署说明
如果 Host 配置了 unpackWARs=true，并且部署了一个 war 文件， 则 war 将被解压缩到 Host appBase 目录中的目录中。
如果应用程序 war 或目录安装在 Host appBase 目录中， 并且 Host 配置了 autoDeploy=true， 或者上下文路径必须与不带 “.war” 扩展名的目录名称或 war 文件名匹配。
为了在不受信任的用户可以管理 Web 应用程序时的安全性， 可以将 Host deployXML 标志设置为 false。 这可以防止不受信任的用户使用配置 XML 文件部署 Web 应用程序， 还可以防止他们部署位于其 Host appBase 外部的应用程序目录或“.war”文件。
部署响应
如果安装和启动成功，将收到如下响应：
OK - Deployed application at context path /foo
否则，响应将以 FAIL 开头并包含错误消息。
问题的可能原因包括：
-
应用程序已存在于路径 /foo 中
当前正在运行的所有 Web 应用程序的上下文路径必须是唯一的。
因此，必须使用此上下文路径取消部署现有 Web 应用程序，
或者为新 Web 应用程序选择不同的上下文路径。
可以将 update 参数指定为 URL 上的参数，其值为 true 以避免此错误。
在这种情况下，在执行部署之前，将对现有应用程序执行取消部署。
-
文档库不存在或不是可读目录
由 war 参数指定的 URL 必须标识此服务器上包含 Web 应用程序的“解包”版本的目录，
或包含此应用程序的 Web 应用程序存档 （WAR） 文件的绝对 URL。
更正 war 参数指定的值。
-
遇到异常
尝试启动新的 Web 应用程序时遇到异常。有关详细信息，请查看 Tomcat 日志，
但可能的原因包括解析 /WEB-INF/web.xml 文件时出现问题，
或在初始化应用程序事件侦听器和筛选器时遇到缺少类。
-
指定的应用程序 URL 无效
指定的目录或 Web 应用程序的 URL 无效。
此类 URL 必须以 file： 开头，WAR 文件的 URL 必须以 “.war” 结尾。
-
指定的上下文路径无效
上下文路径必须以斜杠字符开头。要引用 ROOT Web 应用程序，请使用 “/”。
-
上下文路径必须与目录或 WAR 文件名匹配：
如果应用程序 war 或目录安装在 Host appBase 目录中， 并且 Host 配置了 autoDeploy=true， 则上下文路径必须与不带 “.war” 扩展名的目录名称或 war 文件名匹配。
-
只能安装 Host web application directory （主机 Web 应用程序） 目录中的 Web 应用程序
如果 Host deployXML 标志设置为 false， 则如果尝试在 Host appBase 目录之外部署 Web 应用程序目录或 “.war” 文件，则会发生此错误。
列出当前部署的应用程序
列出当前部署的所有 Web 应用程序的上下文路径、
当前状态（正在运行`或`已停止）和活动会话数。
启动 Tomcat 后立即的典型响应可能如下所示：
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重新加载现有应用程序
向现有应用程序发出信号以自行关闭并重新加载。
当 Web 应用程序上下文不可重新加载，并且在 /WEB-INF/classes 目录中更新了类或属性文件时，
或者在 /WEB-INF/lib 目录中添加或更新了 jar 文件时，这可能很有用。
如果此命令成功，将看到如下响应：
OK - Reloaded application at context path /examples
否则，响应将以 FAIL 开头并包含错误消息。问题的可能原因包括：
-
遇到异常
尝试重新启动 Web 应用程序时遇到异常。 有关详细信息，请查看 Tomcat 日志。
-
指定的上下文路径无效
上下文路径必须以斜杠字符开头。 要引用 ROOT Web 应用程序，请使用 “/”。
-
路径 /foo 不存在上下文
指定的上下文路径上没有已部署的应用程序。
-
未指定上下文路径
path 参数是必需的。
-
在路径 /foo 上部署的 WAR 不支持重新加载
目前，当直接从 WAR 文件部署 Web 应用程序时，
不支持应用程序重新加载（以获取对类或 web.xml 文件的更改）。
仅当从解压缩的目录部署 Web 应用程序时，它才有效。
如果使用的是 WAR 文件，则应`取消部署`，
然后再次`部署`或使用 update 参数部署应用程序以获取更改。
列出 OS 和 JVM 属性
列出有关 Tomcat 版本、OS 和 JVM 属性的信息。
如果发生错误，响应将以 FAIL 开头并包含错误消息。
问题的可能原因包括：
-
遇到异常
尝试枚举系统属性时遇到异常。 有关详细信息，请查看 Tomcat 日志。
列出可用的全局 JNDI 资源
http://localhost:8080/manager/text/resources[?type=xxxxx]列出可用于上下文配置文件的资源链接的全局 JNDI 资源。
如果指定 type 请求参数，则该值必须是感兴趣的资源类型的完全限定 Java 类名
（例如，可以指定 javax.sql.DataSource 来获取所有可用 JDBC 数据源的名称）。
如果不指定 type 请求参数，将返回所有类型的资源。
根据是否指定了 type 请求参数，正常响应的第一行将是：
OK - Listed global resources of all types
或
OK - Listed global resources of type xxxxx
后跟每个资源一行。 每行由冒号字符 （“：”） 分隔的字段组成，如下所示：
-
Global Resource Name（全局资源名称） - 此全局 JNDI 资源的名称，将用于元素的
global属性<ResourceLink>。 -
Global Resource Type（全局资源类型） - 此全局 JNDI 资源的完全限定 Java 类名。
如果发生错误，响应将以 FAIL 开头并包含错误消息。
问题的可能原因包括：
-
遇到异常
尝试枚举全局 JNDI 资源时遇到异常。 有关详细信息，请查看 Tomcat 日志。
-
没有可用的全局 JNDI 资源
正在运行的 Tomcat 服务器已配置为没有全局 JNDI 资源。
会话统计
显示 Web 应用程序的默认会话超时，以及实际超时时间的一分钟范围内的当前活动会话数。 例如，重新启动 Tomcat，然后在 /examples Web 应用程序中执行其中一个 JSP 示例后， 可能会得到如下结果：
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过期会话
显示会话统计信息（如上面的 /sessions 命令）
并使空闲时间超过 num 分钟的会话过期。
要使所有会话过期，请使用 &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实际上，/sessions 和 /expire 是同一命令的同义词。
区别在于存在 idle 参数。
启动现有应用程序
向已停止的应用程序发出重启信号，并使其自身再次可用。 停止和启动非常有用，例如，如果应用程序所需的数据库暂时不可用。 通常，最好停止依赖此数据库的 Web 应用程序，而不是让用户不断遇到数据库异常。
如果此命令成功，将看到如下响应：
OK - Started application at context path /examples
否则，响应将以 FAIL 开头并包含错误消息。
问题的可能原因包括：
-
遇到异常
尝试启动 Web 应用程序时遇到异常。 有关详细信息，请查看 Tomcat 日志。
-
指定的上下文路径无效
上下文路径必须以斜杠字符开头。 要引用 ROOT Web 应用程序，请使用 “/”。
-
路径 /foo 不存在上下文
指定的上下文路径上没有已部署的应用程序。
-
未指定上下文路径
path 参数是必需的。
停止现有应用程序
向现有应用程序发出信号，使其自身不可用，但保持部署状态。 在应用程序停止时传入的任何请求都将看到 HTTP 错误 404， 并且此应用程序将在 list applications 命令上显示为“stopped”。
如果此命令成功，将看到如下响应：
OK - Stopped application at context path /examples
否则，响应将以 FAIL 开头并包含错误消息。 问题的可能原因包括：
-
遇到异常
尝试停止 Web 应用程序时遇到异常。 有关详细信息，请查看 Tomcat 日志。
-
指定的上下文路径无效
上下文路径必须以斜杠字符开头。 要引用 ROOT Web 应用程序，请使用 “/”。
-
路径 /foo 不存在上下文
指定的上下文路径上没有已部署的应用程序。
-
未指定上下文路径 path 参数是必需的。
取消部署现有应用程序
警告 - 此命令将删除此虚拟主机的 appBase 目录（通常为“webapps”）中存在的所有 Web 应用程序项目。
这将删除应用程序 。WAR（如果存在）时，由解压缩形式的部署
或 .WAR 扩展以及 $CATALINA_BASE/conf/[enginename]/[hostname]/ 目录中的 XML 上下文定义。
如果只想让应用程序停止服务，则应改用 /stop 命令。
向现有应用程序发出信号，使其正常关闭自身，
并将其从 Tomcat 中删除（这也使此上下文路径可供以后重用）。
此外，如果文档根目录存在于此虚拟主机的 appBase 目录（通常为“webapps”）中，则会将其删除。
此命令在逻辑上与 /deploy 命令相反。
如果此命令成功，将看到如下响应：
OK - Undeployed application at context path /examples
否则，响应将以 FAIL 开头并包含错误消息。
问题的可能原因包括：
-
遇到异常
尝试取消部署 Web 应用程序时遇到异常。 有关详细信息，请查看 Tomcat 日志。
-
指定的上下文路径无效
上下文路径必须以斜杠字符开头。 要引用 ROOT Web 应用程序，请使用 “/”。
-
不存在名为 /foo 的上下文
没有具有指定名称的已部署应用程序。
-
未指定上下文路径 path 参数是必需的。
查找内存泄漏
http://localhost:8080/manager/text/findleaks?[statusLine=[true|false]]查找泄漏诊断会触发完全垃圾回收。 在生产系统上应格外小心地使用它。
查找泄漏诊断尝试识别在停止、重新加载或取消部署时导致内存泄漏的 Web 应用程序。 结果应始终使用分析器确认。诊断使用 StandardHost 实现提供的其他功能。如 果使用的自定义主机不扩展 StandardHost，它将不起作用。
从 Java 代码显式触发完全垃圾回收被证明是不可靠的。
此外，根据所使用的 JVM，有一些选项可以禁用显式 GC 触发，
例如 -XX：+DisableExplicitGC。
如果要确保诊断程序成功运行了完整的 GC，
则需要使用 GC 日志记录、JConsole 或类似工具进行检查。
如果此命令成功，将看到如下响应：
/leaking-webapp
如果您希望在响应中看到状态行，
请在请求中包含 statusLine 查询参数，其值为 true。
已停止、重新加载或取消部署的 Web 应用程序的每个上下文路径， 但之前运行中的哪些类仍加载到内存中， 从而导致内存泄漏，都将在新行中列出。 如果应用程序已多次重新加载，则可能会多次列出该应用程序。
如果命令不成功，响应将以 FAIL 开头并包含错误消息。
连接器 SSL/TLS 密码信息
SSL 连接器/密码诊断列出了当前为每个连接器配置的 SSL/TLS 密码。
响应将如下所示：
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
...连接器 SSL/TLS 证书链信息
SSL Connector/Certs 诊断列出了当前为每个虚拟主机配置的证书链。
响应将如下所示：
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
...连接器 SSL/TLS 可信证书信息
SSL 连接器/证书诊断列出了当前为每个虚拟主机配置的受信任证书。
响应将如下所示：
OK - Connector / Trusted Certificate information
Connector[HTTP/1.1-8080]
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
...重新加载 TLS 配置
重新加载 TLS 配置文件（证书和密钥文件，这不会触发 server.xml 的重新解析）。
要重新加载所有主机的文件，请不要指定 tlsHostName 参数。
OK - Reloaded TLS configuration for [default]
线程转储
编写 JVM 线程转储。
响应将如下所示：
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 jakarta.servlet.http.HttpServlet.service(HttpServlet.java:618)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:725)
...VM 信息
编写一些有关 Java 虚拟机的诊断信息。
响应将如下所示：
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:
...保存配置
如果指定时不带任何参数，则此命令将服务器的当前配置保存到 server.xml。 如果需要，现有文件将重命名为备份文件。
如果使用与已部署 Web 应用程序的路径匹配的 path 参数指定，
则该 Web 应用程序的配置将保存到当前 Host 的 xmlBase 中适当命名的 context.xml 文件中。
要使用该命令，必须存在 StoreConfig MBean。
通常，这是使用 StoreConfigLifecycleListener 配置的。
如果命令不成功，响应将以 FAIL 开头并包含错误消息。
服务器状态
从以下链接中，可以查看有关服务器的 Status 信息。 任何一个 manager-xxx 角色都允许访问此页面。
http://localhost:8080/manager/status
http://localhost:8080/manager/status/all以 HTML 格式显示服务器状态信息。
http://localhost:8080/manager/status?XML=true
http://localhost:8080/manager/status/all?XML=true以 XML 格式显示服务器状态信息。
http://localhost:8080/manager/status?JSON=true
http://localhost:8080/manager/status/all?JSON=true以 JSON 格式显示服务器状态信息。
首先，有服务器和 JVM 版本号、JVM 提供程序、操作系统名称和编号，然后是架构类型。
其次，有关于 JVM 的内存使用情况的信息。
然后，有关于 Tomcat AJP 和 HTTP 连接器的信息。 都可以获得相同的信息：
-
线程信息 ：最大线程数、最小和最大备用线程数、当前线程数和当前线程繁忙。
-
请求信息 ：最大处理时间和处理时间、请求和错误计数、接收和发送的字节数。
-
显示 Stage、Time、Bytes Sent、Bytes Receive、Client、VHost 和 Request 的表。表中列出了所有现有线程。以下是可能的线程阶段列表：
-
“Parse and Prepare Request” ：正在解析请求标头，或者正在进行读取请求正文的必要准备（如果已指定传输编码）。
-
“Service” ：线程正在处理请求并生成响应。此阶段在 “Parse and Prepare Request” 阶段之后，在 “Finishing” 阶段之前。此阶段 （server-status 页面） 始终至少有一个线程。
-
“Finishing” ：请求处理的结束。仍在输出缓冲区中的响应的任何剩余部分都将发送到客户端。如果适合保持连接活动状态，则此阶段后跟 “Keep-Alive”，如果 “Keep-Alive” 不合适，则后跟 “Ready”。
-
“Keep-Alive” ：线程保持对客户端的连接开放，以防客户端发送另一个请求。如果收到另一个请求，则下一阶段将是 “Parse and Prepare Request”。如果在保持活动状态超时之前未收到任何请求，则连接将关闭，下一阶段将为 “Ready”。
-
“Ready” ：线程处于静止状态，可供使用。
-
如果使用的是 /status/all 命令，
则将提供有关每个已部署的 Web 应用程序的其他信息。
使用 JMX 代理 Servlet
什么是 JMX 代理 Servlet
JMX Proxy Servlet 是一个轻量级代理，用于获取和设置 tomcat 内部。 （或通过 MBean 公开的任何类）它的使用不是很用户友好， 但 UI 对于集成命令行脚本以监控和更改 tomcat 的内部非常有帮助。 可以使用代理做两件事：获取信息和设置信息。 要真正理解 JMX 代理 Servlet，应该对 JMX 有一个大致的了解。 如果不知道 JMX 是什么，请准备好感到困惑。
JMX 查询命令
它采用以下形式：
其中 STUFF 是要执行的 JMX 查询。 例如，以下是可能希望运行的一些查询：
-
qry=%3Atype%3DRequestProcessor%2C -→ type=RequestProcessor将找到所有可以处理请求并报告其状态的 worker。 -
qry=%3Aj2eeType=Servlet%2c -→ j2eeType=Servlet，它返回所有加载的 servlet。 -
qry=Catalina%3Atype%3DEnvironment%2Cresourcetype%3DGlobal%2Cname%3DsimpleValue -→ Catalina：type=Environment，resourcetype=Global，name=simpleValue，它通过给定的名称查找特定的 MBean。
需要对此进行试验才能真正了解它的功能。 如果不提供 qry 参数，则将显示所有 MBean。 强烈建议查看 tomcat 源代码并了解 JMX 规范， 以便更好地了解可能运行的所有查询。
JMX Get 命令
JMXProxyServlet 还支持“get”命令，
可以使用该命令来获取特定 MBean 属性的值。
get 命令的一般形式是：
必须提供以下参数：
get：完整的 bean 名称 att：要获取的属性 key：（可选）CompositeData MBean 属性中的键
如果一切顺利，那么它会说 OK，否则会显示一条错误消息。 例如，假设希望获取当前的堆内存数据：
或者，如果只想要 “used” 键：
JMX Set 命令
现在，可以查询 MBean，是时候处理 Tomcat 的内部结构了！ set 命令的一般形式是：
所以需要提供 3 个请求参数：
-
set：完整的 bean 名称
-
att：要更改的属性
-
val：新值
如果一切正常，则会显示 OK，否则将显示错误消息。
例如，假设希望动态地启动 ErrorReportValve 的调试。
下面将 debugging 设置为 10。
结果是 （YMMV）：
Result: ok
以下是看到的传入错误值的情况。 这是使用的 URL，尝试将调试设置为等于 'cow'：
当尝试时，结果是
Error: java.lang.NumberFormatException: For input string: "cow"
JMX 调用命令
invoke 命令允许在 MBean 上调用方法。
该命令的一般形式为：
例如，要调用 Service 的 findConnectors() 方法，请使用：
使用 Ant 执行 Manager 命令
如上所述，除了能够通过 HTTP 请求执行 Manager 命令之外， Tomcat 还为 Ant（版本 1.4 或更高版本）构建工具提供了一组方便的 Task 定义。 要使用这些命令，必须执行以下设置操作：
-
从 https://ant.apache.org 下载 Ant 的二进制分发版。必须使用版本 1.4 或更高版本。
-
将 Ant 发行版安装在一个方便的目录中（在这些说明的其余部分称为 ANT_HOME）。
-
将
$ANT_HOME/bin目录添加到PATH环境变量中。 -
在 Tomcat 用户数据库中至少配置一个包含
manager-script角色的用户名/密码组合。
要在 Ant 中使用自定义任务，必须先使用元素声明它们`<import>`。
因此，build.xml 文件可能如下所示：
<project name="My Application" default="compile" basedir=".">
<!-- Configure the directory into which the web application is built -->
<property name="build" value="${basedir}/build"/>
<!-- Configure the context path for this application -->
<property name="path" value="/myapp"/>
<!-- Configure properties to access the Manager application -->
<property name="url" value="http://localhost:8080/manager/text"/>
<property name="username" value="myusername"/>
<property name="password" value="mypassword"/>
<!-- Configure the path to the Tomcat installation -->
<property name="catalina.home" value="/usr/local/apache-tomcat"/>
<!-- Configure the custom Ant tasks for the Manager application -->
<import file="${catalina.home}/bin/catalina-tasks.xml"/>
<!-- Executable Targets -->
<target name="compile" description="Compile web application">
<!-- ... construct web application in ${build} subdirectory, and
generated a ${path}.war ... -->
</target>
<target name="deploy" description="Install web application"
depends="compile">
<deploy url="${url}" username="${username}" password="${password}"
path="${path}" war="file:${build}${path}.war"/>
</target>
<target name="reload" description="Reload web application"
depends="compile">
<reload url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
<target name="undeploy" description="Remove web application">
<undeploy url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
</project>注意：通过上述导入定义 resources 任务将覆盖 Ant 1.7 中添加的 resources 数据类型。 如果希望使用 resources 数据类型，则需要使用 Ant 的命名空间 支持来修改`catalina-tasks.xml`以将 Tomcat 任务分配给它们自己的命名空间。
现在，可以执行 ant deploy 等命令将应用程序部署到正在运行的 Tomcat 实例，
或执行 ant reload 命令来告诉 Tomcat 重新加载它。
另请注意，此 build.xml 文件中的大多数相关值都定义为可替换属性，
因此可以从命令行覆盖其值。
例如，可能认为在 build.xml 文件的源代码中包含真实的管理员密码存在安全风险。
为避免这种情况，请省略 password 属性，并从命令行指定它：
ant -Dpassword=secret deploy
任务输出捕获
使用 Ant 版本 1.6.2 或更高版本，Catalina 任务提供了在属性或外部文件中捕获其输出的选项。 它们直接支持 type 属性的以下子集`<redirector>`：
| 属性 | 描述 | 必填 |
|---|---|---|
output |
要将输出写入的文件的名称。如果错误流未同时重定向到文件或属性，它将出现在此输出中。 |
不 |
error |
命令的标准错误应重定向到的文件。 |
不 |
logError |
当希望在 Ant 的日志中看到错误输出并将输出重定向到文件/属性时，会使用此属性。错误输出将不包含在输出文件/属性中。如果使用 error 或 errorProperty 属性重定向 error，则此操作将不起作用。 |
不 |
append |
是应追加输出文件和错误文件还是覆盖输出文件和错误文件。默认为 false。 |
不 |
createemptyfiles |
是否应创建输出和错误文件，即使为空。默认为 true。 |
不 |
outputproperty |
应存储命令输出的属性的名称。除非错误流重定向到单独的文件或流，否则此属性将包含错误输出。 |
不 |
errorproperty |
应存储命令的标准错误的属性的名称。 |
不 |
还可以指定几个其他属性：
| 属性 | 描述 | 必填 |
|---|---|---|
alwaysLog |
当希望查看正在捕获的输出时，会使用此属性，该输出也会显示在 Ant 的日志中。除非正在捕获任务输出，否则不得使用它。默认为 |
不 |
failonerror |
当希望避免任何 manager 命令处理错误终止 ant 执行时，会使用此属性。默认为 |
不 |
它们还支持嵌入元素`<redirector>`，可以在其中指定其完整的属性集，
但 input、inputstring 和 inputencoding 即使被接受，也不会被使用，
因为它们在此上下文中没有意义。有关 element 属性的详细信息，请参阅 ant 手册`<redirector>`。
下面是一个示例构建文件提取，其中显示了如何使用此输出重定向支持：
<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>警告：即使它没有多大意义，而且总是一个坏主意，多次调用 Catalina 任务， 设置错误的 Ant 任务依赖链可能会导致一个任务在同一个 Ant 运行中被多次调用，即使不是故意的。 在捕获该任务的输出时，应小心一点，因为这可能会导致意外情况：
-
在捕获属性时，只会在其中找到第一次调用的输出，因为 Ant 属性是不可变的，一旦设置就无法更改。
-
在文件中捕获时，每次运行都会覆盖它，并且只会在其中找到最后的调用输出，除非使用
append=“true”属性，在这种情况下，将看到每个任务调用的输出都附加到文件中。