tomcat 管理 web程序 war

hitl

http://www.jaxmao.org/

在许多生产环境(production environments)里，这种能力很重要，那就是在不需要关闭和重新启动整个容器的情况下能够部署一个新的web程序，或者反部署一个现有的程序。另外, 你能要求一个现有应用程序再装载它自己，既使你还没有在Tomcat 5服务器配置文件里声明它是可以被重新装载的(reloadable)。

为了支持这种能力，Tomcat 5包含了一个web程序(默认安装在context path /manager上),它支持以下这些功能:

从上载的(uploaded)WAR文件内，把新的web程序部署到指定的context path上去。
Deploy a new web application, on a specified context path, from the server file system.
列出当前部署的web程序，以及这些web程序的活跃着的sessions。
重新装载现有的web程序，以反映出/WEB-INF/classes 或 /WEB-INF/lib 里内容的更改。
列出OS和Java虚拟器(JVM)属性值(property values)。
列出可使用的全球性JNDI资源, 供给正在准备<ResourceLink&gt；套嵌在<Context&gt 的元素；部署描述的开发工具使用。
列出用户数据库里定义的可用安全性功能。
启动运行一个被停止了的程序(让它可再被使用)。
停止一个现有的程序(这样它就变成不可被使用)，但是不undeploy它。
Undeploy a deployed web application and delete its document base directory (unless it was deployed from file system).
有两种方式来配置Manager网络应用程序Context：

把manager.xml context配置文件安装在$CATALINA_HOME/conf/[enginename]/[hostname]文件夹里。
在Tomcat server.xml 配置文件的主机配置(Host configuration)中来配置the Manager Context。下面是一个例子：
<Context path="/manager" debug="0" privileged="true"
docBase="/usr/local/kinetic/tomcat5/server/webapps/manager">
</Context>

如果你把Tomcat配置成可支持多个网站，你就需要为每一个网站单独配置一个管理员(Manager)。

有三种方法来使用管理员(manager)网络应用程序：

作为使用在浏览器上用户接口(user interface)的程序。下面是一个关于URL的例子，这里你可以用你的网站的名字来取代局部主机(localhost): http://localhost/manager/html/。
作为一个使用HTTP(超文本传输协议)请求的小版本程序，它只适合系统管理员用于scripts设置。命令作为这个request URI的一部分给出，并且反应(responses)是那种容易被解析(parsed)和处理的简单文本的形式。更多信息参看被支持的管理员命令( Supported Manager Commands)。
作为Ant(1.4以及其后版本)建造工具的一套简易的task定义。更多信息请参看Executing Manager Commands With ant 。

Tomcat 5的未来版本将包括下面这些形式的管理功能:

作为网络服务，这样Tomcat管理就很容易地整合到远程/或者非Java的管理环境中去。
作为一种具有较好user interface的网络程序(建立在网络服务过程的顶层)，可方便Tomcat通过web浏览器进行管理。


Configuring Manager Application Access
在下面的描述中使用变量名$CATALINA_HOME来代指Tomcat5所安装的目录地址,这是一个基础目录(base directory),其他的相关路径由它而派生。不过，如果你已经把Tomcat设置成多个体实例(multiple instances),并且设立了一个$CATALINA_BASE目录，那么你就应使用$CATALINA_BASE而不是$CATALINA_HOME作为参照。

如果Tomcat里的默认设置允许互联网上的任何人在你的服务器上执行管理员程序(the Manager application)，那就相当不安全了。因此，管理员程序要求每一个使用它的人通过使用带有管理员(manager)角色的用户名称和密码证实它们自己的身份。更进一步，在默认的用户文件中($CATALINA_HOME/conf/tomcat-users.xml)没有用户名称被指派这个角色。因此，以默认的形式是完全不可能访问管理员程序的。

为了能进入管理员程序进行存取，你必须产生一个新的用户名称/密码组合，并把它们与管理员(manager)角色联系在一起，或者把管理员(manager)角色添加给现有的用户名称/密码组合。在什么确切的地方做上面这些工作依赖于你使用了哪个Realm implementation ：

MemoryRealm ——别如果你还没有客户化$CATALINA_HOME/conf/server.xml，就选择另外一个文件，Tomcat 5默认选用存放在$CATALINA_HOME/conf/tomcat-users.xml里的一个XML-格式的文件，它可以由任何文字编辑器(text editor)来编辑。这个文件为每一个用户包括了一个XML <user>，它看上去可能象这样：
   
<user name="craigmcc" password="secret" roles="standard,manager" />
  
   

它定义了用于个人登录使用的用户名称和密码，以及他(她)们相关联的角色名称。你可以给现有的一个或多个用户添加“管理员(manager)”角色，或者产生具有管理员角色的新用户。
JDBCRealm —— 关于用户以及其角色的信息被存放在数据库里，通过JDBC(Java数据库连接)进行存取。按照你使用的工作环境里的标准手续来给一个或多个现有用户添加“管理员(manager)"职责，或者产生一个或多个具有管理员角色的新用户。
JNDIRealm —— 关于用户以及其角色的信息被存放在目录服务器上，通过LDAP进行存取。按照你使用的工作环境里的标准手续来给一个或多个现有用户添加“管理员(manager)”职责，或者产生一个或多个具有管理员角色的新用户。
当你第一次试图发布一个下个章节将要描述的Manager命令时，你会被要求用BASIC认证来登入。不管你输入什么用户名称和密码，只要它们是能被用户数据库识别的具有管理员(manager)角色的用户就行。

除了密码制约之外，在远程IP地址或主机上增加RemoteAddrValve或者RemoteHostValve也可以对管理员网络程序进行限制。下面的例子是通过IP地址对进出局部主机(localhost)进行限制:

<Context path="/manager" debug="0" privileged="true"
docBase="/usr/local/kinetic/tomcat5/server/webapps/manager">
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1"/>
</Context>


Supported Manager Commands
管理员程序的所有命令都是由象这样的单个request URI指定(它的格式如下):

   
http://{host}:{port}/manager/{command}?{parameters}
  
   

这里{host}和{port}代表主机名称和Tomcat运行的端口(port)数目，{command}代表你想要执行的管理员命令，{parameters}代表那个命令特有的查询参数。在下面的说明里，把主机和端口适当地客户化以便进行安装。

多数命令接受以下一个或多个查询参量:

路径(path)——你将要处理的网络应用程序的上下文路径(包括前面的“/”)。要选择the ROOT网络应用程序，指定"/"。注意——不可能仅仅在管理员程序自身就能执行管理命令。
网络应用程序档案(war)—— 网络应用程序档案文件的统一资源定位器(URL)，包含网络程序的目录的路径名称，或者是一个Context configuration ".xml" 文件。你可以以下面任何格式使用URLs:
file:/absolute/path/to/a/directory ——这是通向包含未包装版的网络程序目录的绝对路径。这个目录可以附加在你指定的context path上，而不需要任何改变。
file:/absolute/path/to/a/webapp.war —— 这是通向网络应用档案(WAR)文件的绝对路径。这仅仅对/deploy 命令有效，也是这个命令唯一被接受的格式。
jar:file:/absolute/path/to/a/warfile.war!/ —— 这是通向局部网络应用档案(WAR)文件的URL。你可以使用任何对JarURLConnection class有效的语法来代指一整个JAR文件。
file:/absolute/path/to/a/context.xml —— 这是通向网络应用上下文配置 ".xml"文件的绝对路径，这个".xml"文件包含有上下文配置元素。
directory (目录)—— 主机的应用基础目录中各种web程序内容的子目录名称。
webapp.war —— 这是网络程序war文件的名称，它被放置在主机的应用基础目录上。
每个命令都会产生一个text/plain 形式的反应(response)(例如，简单的ASCII而没有HTML修饰)，使它能容易地被人或机器阅读。反应(response)的第一行通常以OK(可以)或者FAIL(失败)开始，表明了这个请求命令被成功执行与否。如果出现失败，第一行的剩余部分会描述你所遇到的问题。下面将描述一些命令及其额外的信息。

Internationalization Note(国际化注意事项):管理员程序从资源束(resource bundles)里查看消息字串(message strings)，所以有可能这些字串已被翻译过以适用于你的工作平台。下面的例子显示的是英文版的消息(messages)。

警告：以前使用的命令 /install 和 /remove 不再被使用了。它们现在等同于/deploy 和 /undeploy命令，在以后的发行版中可能会被删除掉。

Deploy A New Application Remotely
   
http://localhost:8080/manager/deploy?path=/foo
  
   

上装(Upload)在HTTP PUT request里特指的WAR文件，然后把它安装在相应的虚拟主机(virtual host)的appBase目录上，在路径请求参数特指的context path 上启动运行。如果没有指定路径，那么目录名称或者不带有.war 扩展名的WAR文件名称就被当作路径。这个应用程序在以后可以通过使用/undeploy 被取消部署(相关的程序目录也会被删除)。

这个.WAR 文件可以通过在/META-INF/context.xml里包含一个上下文配置XML 文件来包括 Tomcat特指的部署配置。

URL参数包括：

更新(update)：当被设置为正确(true)时，已有的更新参数会被首先取消部署。默认值是被设为错误(false)。
标志(tag)：指定一个标志名称，这样允许把版本数目与被部署的网络程序相关联。以后可以只用标志(tag)就可以重新部署这个版本的程序。

注意 —— 这个命令在逻辑上和/undeploy命令相反。

如果安装和启动成功，你会收到象下面这种回应：

   
OK - Deployed application at context path /foo
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

应用程序已经存在于path /foo
所有当前运行的网络程序的context paths 必须是独特（彼此不同）的。因此，你必须取消部署现有的使用这个context path的网络程序，或者为新程序选择一个不同的context path 。update参数必须指定为URL上的一个参数，为避免错误，把参数值设为true 。这样，在部署新程序前会对现有程序执行取消部署。

遇到异常
当试图启动新程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)，不过通常的解释多为在语法分析(parsing)/WEB-INF/web.xml 文件时遇到问题，或者是在初始化程序事件(event)监听器(listeners)或过滤器(filters)遇到了缺失的类(missing classes)。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

没有指定上下文路径
路径参数是必需的。
Deploy A New Application from a Local Path
安装和启动一个新的网络程序，把它和特定的上下文路径相连(这个上下文路径不能被其他网络程序使用)。这个命令(指deploy)与/undeploy 命令在逻辑意义上相反。

有许多种不同的办法来使用deploy命令:

部署一个以前被部署过的网络程序版本
这可以用来部署一个以前版本的网络程序，这个程序曾被使用标志(tag)属性部署过。注意，管理员程序的工作目录必须包含以前部署过的WARs；删除它会使得这里的部署失败。

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


通过URL部署一个目录或者WAR
部署Tomcat服务器上的网络程序目录或者".war"文件。如果没有指定路径(path)，那么目录名称或者不带有".war"扩展名的WAR文件名称就被当作路径。网络应用程序档案(war)参数为每个目录或WAR文件指定了URL(包括文件: scheme)。关于URL指向WAR文件的语法在Javadocs页面java.net.JarURLConnection class里有描述。只能使用那些指向全部(entire)WAR文件的URL。

在下面的这个例子里，位于Tomcat服务器/path/to/foo目录里的网络程序被部署为一个名叫/footoo 的网络程序context。

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


在下面的这个例子里，位于Tomcat服务器上的".war"文件/path/to/bar.war被部署为一个名叫/bar 的网络程序context。注意，这里没有path参数，所以在默认的情况下，context path指向不带有".war"扩展名的网络应用程序档案文件。

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


在主机的appBase部署一个目录或War文件
在主机的appBase目录里部署一个网络程序目录或".war"文件。如果没有指定路径(path)，那么目录名或者不带有".war"扩展符的WAR文件名称就被当作路径。

在下面的这个例子里，位于Tomcat服务器主机appBase目录下的子目录foo里面的网络程序被部署为叫作/foo 的网络程序context。注意，这里没有path参数，所以在默认的情况下，context path指向网络程序目录名。

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


在下面的这个例子里，位于Tomcat服务器主机appBase目录里的".war"文件bar.war被部署为名叫/bartoo 的网络程序context。

   
http://localhost:8080/manager/deploy?path=/bartoo&war=bar.war
  
   


使用上下文语境配置".xml"文件进行部署
如果主机(Host) deployXML旗标被设置为正确(true)，你可以用上下文语境配置".xml"文件，或者".war"文件，或者程序目录来部署你的网络程序。当使用上下文语境配置".xml"文件来部署网络程序时，不需要使用context path。

一个上下文语境配置".xml"文件可包括有效的网络程序上下文XML文件，就象在Tomcat server.xml 配置文件里被配置过一样。下面是个示例：

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

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

</Context>
  
   


当可任选的网络应用程序档案(war)参数被设置指向一个web程序的".war"文件或目录的URL时,它会取代任何在上下文配置".xml"文件里配置的docBase 。

这里是使用上下文语境配置".xml"文件部署一个应用程序的例子。

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


这个例子是使用上下文语境配置".xml"文件和一个位于服务器上的".war"文件来部署一个应用程序。

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


部署注意事项
如果主机(Host)配置为unpackWARs=true ，并且你部署了一个war文件，那么，这个war文件就会被unpacked到主机的appBase目录上。

如果war文件或者目录被安装到主机的appBase目录上，并且主机被配置为autoDeploy=true 或者liveDeploy=true ，那么Context path 必须与目录名或不带有".war"扩展符的war文件名相配。

因为安全原因，当不可靠用户来管理网络程序时，主机的deployXML旗标可以设置为false 。这就使不可靠用户不能够使用配置XML文件来部署web程序，也不能部署位于主机appBase之外的目录或".war"文件。

部署回应
如果安装和启动成功，你会收到象下面这种回应：

   
OK - Deployed application at context path /foo
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

应用程序已经存在于path /foo
所有当前运行的网络程序的context paths 必须是独特（彼此不同）的。因此，你必须取消部署现有的使用这个context path的网络程序，或者为新程序选择一个不同的context path 。update参数必须指定为URL上的一个参数，为避免错误，把参数值设为true 。这样，在部署新程序前会对现有程序执行取消部署。

文档base不存在或者是一个不可读取的目录
由网络应用程序档案(war)参数指定的URL必须识别这个服务器上包含"unpacked"版本的网络程序目录，或者包含这个程序的网络应用程序档案(WAR)的绝对URL。修正这个网络应用程序档案(war)参数指定值。

遇到异常
当试图启动新程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)，不过通常的解释多为在语法分析(parsing)/WEB-INF/web.xml 文件时遇到问题，或者是在初始化程序事件(event)监听器(listeners)或过滤器(filters)遇到了缺失的类(missing classes)。

指定的程序URL无效
你为目录或网络程序指定的URL是无效的。这样的URL必须以“file:”开始，为WAR文件提供的URL必须以".war"结束。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

上下文路径必须与目录名或WAR文件名相配
如果war文件或者目录被安装到主机的appBase目录上，并且主机被配置为autoDeploy=true 或者liveDeploy=true ，那么Context path 必须与目录名或不带有".war"扩展符的war文件名相配。
只有在主机网络程序目录里的web程序才能被安装
如果主机的deployXML旗标被设为false，要是试图部署位于主机appBase目录之外的网络程序目录或".war"文件，就会出现错误。
List Currently Deployed Applications
   
http://localhost:8080/manager/list
  
   

列出所有当前被部署过的程序的context paths，当前状态(运行中的或停止的)，以及活动会话(active sessions)数目。在启动Tomcat后马上出现的典型回应可能象这样：

   
OK - Listed applications for virtual host localhost
/webdav:running:0
/examples:running:0
/manager:running:0
/:running:0
  
   

Reload An Existing Application
   
http://localhost:8080/manager/reload?path=/examples
  
   

向一个现有的程序发出信号去把它自己关闭然后再重新装载。当程序的context不能够被重新装载，但你/WEB-INF/classes目录中有更新过的类或属性文件，或者在/WEB-INF/lib目录中添加或更新过jar文件，上面这个办法就很有用。

注意 —— /WEB-INF/web.xml 网络程序配置文件不能在被重新装载时被再次读取。如果你更改了web.xml文件，你必须停止运行，然后再启动网络程序。

如果这个命令成功，你会看到象下面这样的回应：

   
OK - Reloaded application at context path /examples
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

遇到异常
当试图重新启动网络程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

path /foo 上没有存在context
在你指定的context path上没有被部署过的程序。

没有指定上下文路径
路径参数是必需的。
在path /foo上部署的WAR文件不支持重新装载
目前，当网络程序从一个WAR文件直接被部署时，程序的重新装载(拾起classes 或 web.xml文件里的更改)就不被支持。重新装载仅仅适用于那些从未包装目录那里部署的程序。如果你在使用WAR文件，要拾起(pick up)那些更改，你应该先undeploy(旧的文件)，然后再deploy这个程序，或者以update的参数来部署这个程序。
List OS and JVM Properties
   
http://localhost:8080/manager/serverinfo
  
   

列出关于Tomcat版本，OS, 和 JVM属性的信息。

如果出现错误，回应(response)将是以FAIL开头的一段错误消息。产生错误的可能原因包括：

遇到异常
在枚举系统属性时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

List Available Global JNDI Resources
   
http://localhost:8080/manager/resources[?type=xxxxx]
  
   

列出可用于上下文配置文件资源链接(resource links)的全球性JNDI资源。如果你指定类型请求参数(type request parameter)，参数值必须是你所感兴趣的资源类型中完全合格的Java class name(例如，你得要指定javax.sql.DataSource 来取得所有可用的JDBC数据源的名称)。如果你没有指定类型请求参数，所有类型的资源将被返回。

依赖于类型请求参数(type request parameter)被指定与否，通常回应的第一行会是这样：

OK - Listed global resources of all types
or

OK - Listed global resources of type xxxxx
然后是每一行对应一个资源。每一行由以冒号(":")为界限的如下区域组成：

全球性资源名称(Global Resource Name) —— 全球性JNDI资源的名称，它将被用在<ResourceLink>元素的全球性属性中。
全球性资源类型(Global Resource Type)—— 全球性JNDI资源的完全合格的Java class 名称。
如果出现错误，回应(response)将是以FAIL开头的一段错误消息。产生错误的可能原因包括：

遇到异常
在枚举全球性JNDI资源时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

全球性JNDI资源不存在
你在运行的Tomcat服务器没有被配置全球性JNDI资源。

List Available Security Roles
   
http://localhost:8080/manager/roles
  
   

列出在org.apache.catalina.UserDatabase资源里的安全性能名称(以及相应的描述)，这个资源与Manager网络程序里web.xml文件中的用户资源索引相链连。例如，这通常会被那些想要产生 <security-role-ref>元素的部署工具使用，而<security-role-ref>元素是用来映射网络程序里的安全性能名称和容器里实际上被定义的角色名称的。

在默认的情况下，用户资源索引指向全球性UserDatabase资源。如果你选择让每个虚拟器使用不同的用户数据库，你应该修改默认的manager.xml 配置文件里的<ResourceLink> 元素，让它指向这个虚拟器的全球性用户数据库资源。

当这个命令被执行后，回应的第一行是这样的：

OK - Listed security roles
然后是每一行对应一个安全性能。每一行由以冒号(":")为界限的如下区域组成：

安全性能名称(Security Role Name)——用户数据库里Tomcat所知道的安全性能名称。
描述(Description)——关于这个安全性能的描述(对于产生选定功能的用户界面有用)
如果出现错误，回应(response)将是以FAIL开头的一段错误消息。产生错误的可能原因包括：

Cannot resolve user database reference —— 一个JNDI错误，阻止了成功查询org.apache.catalina.UserDatabase 资源。关于这类错误，请查看Tomcat log 文件的stack trace 。
No user database is available —— 你还没有为用户资源配置一个可以指向适当的用户数据库实例(instance)的资源索引。检查一下你的manager.xml文件，确保你为这个资源产生了一个适合的<ResourceLink>或<ResourceParams>元素。

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

显示一个网络程序的默认session timeout，以及在实际timeout时间十分钟左右范围里的活动sessions数目。例如，在重新启动Tomcat和执行/examples程序里的一个JSP样本以后，你可能会得到象下面这样的东西：

   
OK - Session information for application at context path /examples
Default maximum session inactive interval 30 minutes
30 - <40 minutes:1 sessions
  
   

Start an Existing Application
   
http://localhost:8080/manager/start?path=/examples
  
   

向一个被停止运行的程序发出重新启动的信号，使它可以再被使用。停止和启动(这两个命令)是有用处的，例如，在你的程序所必需的数据库临时unavailable时。通常停止运行依赖于这个数据库的程序，比起让用户不断地遇到数据库异常要好一些。

如果这个命令成功，你会看到象下面这样的回应：

   
OK - Started application at context path /examples
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

遇到异常
当试图启动网络程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

path /foo 上没有存在context
在你指定的context path上没有被部署过的程序。

没有指定上下文路径
路径参数是必需的。
Stop an Existing Application
   
http://localhost:8080/manager/stop?path=/examples
  
   

向一个现有的程序发出信号，使它自己变成不能被使用，但让它还是被部署着。当一个程序被停止运行，任何一个进来的请求都会看到一个HTTP错误404，而且在执行list applications命令时，这个程序会显示为"stopped"。

如果这个命令成功，你会看到象下面这样的回应：

   
OK - Stopped application at context path /examples
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

遇到异常
当试图停止运行网络程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

path /foo 上没有存在context
在你指定的context path上没有被部署过的程序。

没有指定上下文路径
路径参数是必需的。
Undeploy an Existing Application
   
http://localhost:8080/manager/undeploy?path=/examples
  
   

警告：这个命令将会删除存在于虚拟主机appBase 目录下的(典型名称叫做"webapps")任何web程序内容。也会删除源代码.WAR文件，如果存在的话。这个appBase目录的内容或者是从未包装的程序部署过来的，或者是.WAR 扩展而来的，它还包括$CATALINA_HOME/conf/[enginename]/[hostname]/ 目录里的XML Context定义。如果你仅仅只想让程序停止工作，你就使用/stop命令。

向一个现有的程序发出关闭信息，把它自己从Tomcat里删除(这就使得这个context path以后可以被再使用)。另外，存在于虚拟主机appBase目录(典型名称 "webapps")上的文件根目录(document root directory)也被删除掉了。这个命令在逻辑上和/deploy 命令相反。

如果这个命令成功，你会看到象下面这样的回应：

   
OK - Undeployed application at context path /examples
  
   

否则,回应(response)将是以FAIL为首的一段错误消息。产生错误的可能原因包括：

遇到异常
当试图取消部署网络程序时，遇到了异常。详细问题去查看Tomcat 5日志(logs)。

指定的上下文路径是无效的
Context path必须以一个slash符号开始。使用"/"代指ROOT网络应用程序。

path /foo 上没有存在context
在你指定的context path上没有被部署过的程序。

没有指定上下文路径
路径参数是必需的。

Executing Manager Commands With Ant
除了象上面所讲的可以通过HTTP请求来执行Manager命令，Tomcat 5还包括了一套使用方便的Ant(1.4及其后版本)构造工具的任务定义。为了能够使用这些命令，你必须进行下面的操作设置：

从http://ant.apache.org下载Ant的binary distribution 。你必须使用1.4或其后版本。
把Ant distribution 安装在一个方便的目录(在这个说明的其余部分被称作ANT_HOME)。
把文件server/lib/catalina-ant.jar从Tomcat 5安装复制到Ant的library目录($ANT_HOME/lib)。
把$ANT_HOME/bin目录添加到PATH环境变量中。
在Tomcat具有管理员(manager)角色的用户数据库里至少配置一个用户名/密码组合。
要在Ant里使用客户化的任务，你必须事先用<taskdef>元素对它们进行声明。因此，你的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"/>
<property name="username" value="myusername"/>
<property name="password" value="mypassword"/>

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

<!-- 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="${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>


现在，你可以执行象ant deploy这样的命令向运行的Tomcat实例部署应用程序，或者用ant reload来告诉Tomcat对程序进行重新装载。请注意，在build.xml文件中大多数有趣的参数值都被定义为可被替换的属性，这样一来你可以从命令行来替代(override)它们的参数值。例如，你可能认为把真实管理员密码写在build.xml的源代码里会对安全性能造成危险。为避免这样，你可以忽略密码这个属性，然后从命令行来指定它：

ant -Dpassword=secret deploy
Tasks output capture
使用Ant 1.6.2或其后版本，Catalina tasks在属性文件或外部文件里提供捕捉它们的输出信息的选项。 它们直接支持下列<redirector>类型attributes的下属属性：

属性 描述 是否必要
output 向其进行输出的文件名。如果error stream没有被重新指向一个文件或属性，那么它就出现在这里。 No
error 标准的错误信息输出命令应该指向这个文件。 No
logError 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 error or errorProperty attributes, this will have no effect. No
append 输出和错误文件是否应该被附加上或被overwritten。默认设置是false。 No
createemptyfiles 即使在输出和错误文件是empty时，它是否应该被产生。默认设置是true。 No
outputproperty 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. No
errorproperty The name of a property in which the standard error of the command should be stored. No

A couple of additional attributes can also be specified:

属性 描述 是否必要
alwaysLog 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 false. This attribute will be supported directly by <redirector> in Ant 1.6.3 No
failonerror This attribute is used when you wish to avoid that any manager command processing error terminates the ant execution. Defaults to true. It must be set to false, if you want to capture error output, otherwise execution will terminate before anything can be captured.
This attribute acts only on manager command execution, any wrong or missing command attribute will still cause Ant execution termination.  No

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.



Using the JMX Proxy Servlet
What is JMX Proxy Servlet
JMX Proxy Servlet是用来获取和设置Tomcat内部组织的轻型代理。(或者任何通过MBean被exposed过的类)。 它的用法对客户来说不方便，但是它的UI对于整合命令行scripts来监督和改变Tomcat内部组织很有帮助。你可以用代理来做两件事：获取信息和设置信息。你必须对JMX有个基本了解才能真正理解JMX Proxy Servlet。如果你不知道JMX是什么，那你就会感到迷惑。
JMX Query command
以这种形式：
   
http://webserver/manager/jmxproxy/?qry=STUFF
  
   

这里STUFF是你想要执行的查询(query)。例如，这里是一些你想要运行的查询(queries)：
qry=*%3Atype%3DRequestProcessor%2C* --> type=RequestProcessor 找出所有的可以处理请求以及汇报它们的状态的 workers 。
qry=*%3Aj2eeType=Servlet%2c* --&gt; j2eeType=Servlet 会返回所有装载的servlets。
qry=Catalina%3Atype%3DEnvironment%2Cresourcetype%3DGlobal%2Cname%3DsimpleValue --&gt; Catalina:type=Environment,resourcetype=Global,name=simpleValue 由所给出的名字查看一个特定的MBean。
你得要真正试一试这些查询(queries)才能真正知道它的能力。如果你没有提供qry参数，那么所有的MBeans就会被显示出来。我们极力建议你先去读一读tomcat源代码并弄懂JMX规范，这样你就会更好地理解你运行的那些queries了。
JMX Set command
你可以查询一个MBean,现在是"搅乱"Tomcat内部组织的时候了! 这个set命令的一般形式是:
   
http://webserver/manager/jmxproxy/?set=BEANNAME&amp;att=MYATTRIBUTE&amp;val=NEWVALUE
  
   

这样,你必须提供三个请求参数:
set: 完整的bean名字
att: 你想要改变的特性(attribute)
val: 新的值
如果所有都顺利，机器就会说OK，不然就会出现一段错误消息。例如，我们想要打开ErrorReportValve的排错(debugging)功能，下面将把debugging值设为10:
   
http://localhost:8080/manager/jmxproxy/
?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost&amp;att=debug&amp;val=10
  
   

所得结果是(YMMV):
   
Result: ok
  
   

如果我传送一个坏的值，就会看到下面这种情况。这里我是使用的URL，我把debugging值设为'cowbell':
   
http://localhost:8080/manager/jmxproxy/
?set=Catalina%3Atype%3DValve%2Cname%3DErrorReportValve%2Chost%3Dlocalhost&amp;att=debug&amp;val=cowbell
  
   

当试着执行它时，结果是：
   
Error: java.lang.NumberFormatException: For input string: "cowbell"