Tomcat配置文件server.xml解析

概述

Tomcat安装目录中的conf/server.xml用于配置Tomcat Servlet/JSP容器的行为，本文介绍server.xml中的各配置元素的相关信息。配置元素主要分为以下几个种类：

• 顶层元素
  <Server>是配置文件的根元素，<Service>代表一组连接器（Connector）和与之关联的一个引擎（Engine）的组合。
• 连接器
  代表客户端发送请求到的特定服务（Service）以及从服务获取相应的接口。
• 容器
  代表用于处理请求并产生相应响应的一类组件。一个引擎（Engine）处理所在服务（Service）的所有请求；一个虚拟主机（Host）处理该虚拟主机的所有请求，一个上下文（Context）处理该Web应用的所有请求。
• 嵌套组件
  表示可以嵌套在容器内部的元素。有些元素可以嵌套在任何容器，有些只能嵌套在Context元素内部。

顶层元素（Top Level Elements）

1. Server

1）简介
Server元素表示整个Servlet容器。它是配置文件的根元素，它的属性代表整个servlet容器的特征。

2）公共属性

属性名	描述
className	Server组件的具体实现对应的的Java类的名称，它必须实现org.apache.catalina.Server接口，如果没有配置该属性，默认使用标准实现，Server的标准实现Java类为 org.apache.catalina.core.StandardServer
address	用于接收shutdwn指令的TCP/IP的地址，如果没有配置该属性，默认使用localhost
port	用于接收shutdwn指令的TCP/IP的端口，设置为-1可以禁用关闭指令端口
shutdown	通过TCP/IP协议从特定端口接收的指令字符串，用于关闭Tomcat服务器

2. Service

1）简介
Service元素代表一个或多个Connector组件（用于接收请求）和与之关联的一个Engine组件（用于处理请求）的组合。Server元素可以内嵌一个或多个Service元素。

2）公共属性

属性名	描述
className	Service组件的具体实现对应的Java类的名称，它必须实现org.apache.catalina.Service接口，如果没有配置该属性，默认使用标准实现，Service的标准实现Java类为 org.apache.catalina.core.StandardService
name	Service组件的名称，标准实现中会用于日志信息。Server中每个Service名称必须唯一

线程池（Eecutors）

1. Executor

1）简介
Executor代表可以在Tomcat各组件之间共享的线程池。默认每个Connector会实现自己的线程池，但是现在允许各个Connector组件和其它支持线程池的组件共享线程池。Executor元素内嵌于Service元素，并且应该出现在Connector元素之前，以便被Connector组件选择使用。

2）公共属性

属性名	描述
className	Executor组件的具体实现对应的Java类的名称，它必须实现org.apache.catalina.Executor接口，如果没有配置该属性，默认使用标准实现，Executor的标准实现Java类为 org.apache.catalina.core.StandardThreadExecutor
name	用于在server.xml中的其他位置引用此池的名称。 该名称是必需的且唯一的。

连接器（Connectors）

1. Http/1.1 Connector

1）简介
HTTP Connector元素表示支持 HTTP/1.1协议的Connector组件，它使Catalina除作为Servlet/JSP容器外，还具备作为独立的Web服务器的功能。一个服务（Service）可以有一个或多个Connector，运行在服务器端的每个Connector组件的实现监听特定的TCP端口，将请求转发到关联的Engine组件进行处理并生成相应。

Connector组件接收每个请求期间需要一个线程进行处理，如果并发请求数超过当前可用线程数，额外的线程将会被创建直到达到当前Connector组件允许创建的最大线程数（由maxThreads属性设置，默认200，如果配置了线程池组件，该属性将被忽略），如果仍有更多并发请求，它们将堆叠在当前Connector组件创建的server socket内（一个队列），直到达到最大值（由acceptCount属性设置，默认100），如果仍有更多并发请求，将会被拒绝。

2）公共属性

属性名	描述
allowTrace	设置是否支持请求方法Trace，默认为false
asyncTimeout	异步请求的超时时间，单位为毫秒，默认为30000
maxHeaderCount	请求携带的请求头最大数量，超出限制请求会被拒绝，设置为负数表示不限制数量，默认为100
maxParameterCount	请求携带的参数最大数量（GET和POST），超出请求会被拒绝，设置为负数表示不限制数量，默认为10000
port	Connector组件创建服务器套接字并等待连接的TCP端口，如果设置为0，Tomcat将会为此Connector随机选择一个可用的端口号，这通常仅适用于嵌入式和测试应用程序
protocal	设置协议以处理传入流量，默认值为HTTP / 1.1
redirectPort	如果此Connector支持非SSL请求，并且收到匹配的请求需要SSL传输，则Catalina将自动将请求重定向到此处指定的端口号
connectionTimeout	用于设置建立连接后，Connector等待请求URI呈现的毫秒数

容器（Containers）

1. Engine

1）简介
Engine元素表示对特定服务（Service）的全部请求的处理器。它从一个或多个连接器（Connector）接收请求并返回完整的响应给连接器以便最终传送给客户端。Engine元素必须内嵌于Service元素中并跟随在Connector元素之后。

2）公共属性

属性名	描述
defaultHost	默认主机名，当发往本机的请求指定的host名称不存在时，将使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。
name	Engine组件的逻辑名称，用于日志和错误信息，在整个Server中必须唯一

2. Host

1）简介
Host元素表示虚拟主机，在Tomcat正在运行的服务器（Server）和服务器的网络名称（域名）之间建立关联，使客户端能够通过域名访问服务器。如通过www.baidu.com访问百度服务器。

一个或多个Host元素内嵌于Engine元素中，Host元素可以内嵌Context元素（代表与此虚拟主机关联的Web应用），至少有一个Host元素name属性与Engine元素的defaultHost属性匹配。

客户端通常通过主机名访问服务器，主机名将会包含在HTTP请求头中，Tomcat会截取此信息用于匹配服务器上的虚拟主机，如果没有找到，则使用默认主机处理请求。

2）公共属性

属性名	描述
appBase	此虚拟主机的xml基目录，这是可能包含要在此虚拟主机上发布的Web应用的文件夹的路径，可以是绝对路径，也可以是相对路径（相对于$CATALINA_BASE），默认值为"webapps"
xmlBase	这是可能包含要在此虚拟主机上发布的Web应用的xml描述文件的文件夹的路径，可以是绝对路径，也可以是相对路径（相对于$CATALINA_BASE），默认值为“conf/<engne_name>/<host_name>”
autoDeploy	此标志值指示Tomcat是否应在Tomcat运行时定期检查新添加的或更新的Web应用程序。 如果为true，则Tomcat会定期检查appBase和xmlBase目录，并部署找到的所有新添加的Web应用程序 和重新加载更新的Web应用程，默认值为true
deployOnStartup	此标志指示Tomcat启动时应自动发布此虚拟主机的Web应用，默认值为true
name	虚拟主机的名称，可以使用*.domainname(例如：*.apache.org)，它会匹配该域下所有主机名，除非有完全匹配

2）标准实现属性

属性名	描述
copyXML	如果想要将嵌入在web应用内的context.xml文件（位于/META-INF/context.xml）在应用首次启动时复制到xmlBase中，设置为true。在随后启动应用程序时，xmlBase中的context配置文件将会优先被使用，即便web应用内有更新的context配置文件。默认值为false。注意如果 deployXML设置为fasle，此属性将无效
deployXML	如果要禁用解析嵌入在web应用内的context.xml文件（位于/META-INF/context.xml），则设置为false。安全意识环境应将此设置为false以防止应用程序与容器的配置交互。然后，管理员将负责提供外部上下文配置文件，并将其放在xmlBase属性定义的位置。如果此标志为false，context配置文件位于于/META-INF/context.xml，并且xmlBase中不存在context配置文件，应用程序将无法启动，因为context.xml可能包含安全部署的必要配置（例如RemoteAddrValve），不应该被忽视。默认值为true，如果启用安全管理器，默认为false。在安全管理器下运行时，可以通过向web应用程序授予org.apache.catalina.security.DeployXmlPermission来基于每个Web应用程序启用此功能。默认情况下，Manager和Host Manager应用程序被授予此权限，以便它们在安全管理器下运行时继续工作。
workDir	临时目录文件夹，默认为$CATALINA_BASE/work

3）应用程序自动部署

当使用Host组件的标准实现与默认配置时，appbase中的Web应用程序和xmlbase中的context配置文件指定的Web应用将会在Tomcat启动时自动部署（Host元素的deployOnStartup属性默认为true ），并且Tomcat运行时如果检测到变化将会重新发布或重新加载Web应用程序（Host元素的autoDeploy属性默认为true ）。

当使用自动部署时，虚拟主机appBase和xmlBase中的相关文件（Web应用程序的context.xml文件或.war文件或文件夹）必须符合期望的命名规则（后面会有具体介绍）。

自动部署过程使用以下搜索顺序识别新的或已修改的Web应用程序：

• 在Host xmlBase中的配置文件指向的Web应用程序
• 在HostappBase中的还没有被识别的war格式Web应用程序
• 在Host appBase中的还没有被识别的文件夹格式Web应用程序

当Host元素的autoDeploy属性为true时，自动部署程序将会监视web应用的变化。web应用程序将会被重新部署（re-deployed）会重新加载(reloaded)，取决于监测到的变化情况。重新部署牵涉到创建新的web应用的情况，如果使用的是标准session manger，用户session信息将会丢失。重新加载使用存在的web应用，重新解析其web.xml文件并重新加载class文件，如果使用的是标准session manger，用户session信息不会丢失。

用户可以添加文件到自动部署程序监视的范围（一旦这些文件发生改变。会触发web
应用reloaded），通过添加WatchedResources元素到context.xml 文件。

当使用自动部署时context.xml中的docBase应在webApp之外，否则自动部署Web应用程序是可能会出问题，或者可能会部署应用程序两次。

如果在Host元素内嵌Context元素，则应关闭自动部署或小心指定 deployIgnore属性，否则可能会部署应用程序两次并且这可能会导致应用程序出现问题。

3. Context

1）简介
Context元素代表一个运行在特定虚拟主机上的Web应用，每个Web应用体现为一个War格式文件或是包含者未压缩内容的文件夹。

用于处理每个HTTP请求的Web应用程序由Catalina将Request URI的最长可能前缀与每个定义的Context的路径进行匹配来选择。 选择后，该Context将根据Web应用程序定义的servlet映射选择适当的servlet来处理传入的请求。

可以根据需要定义任意数量的Context元素，每个Context元素必须有虚拟主机内唯一的Context名称，但Context路径可以不唯一（并行部署的情况）。可能存在一个Context的路径是空字符串，此Context将作为此虚拟主机的默认应用，用于处理与虚拟主机内其它Context路径均无法匹配的请求。

2）并行部署
可能会同时出现部署同一个应用程序多个版本的情况，它们的Context路径相同，用于将请求与Context版本进行匹配的规则如下：

• 如果该请求没有session信息，将匹配最新版本；
• 如果该请求有session信息，那么检查每个版本的session manager进行session匹配，匹配成功则使用该版本;
• 匹配失败则使用最新版本。

3）命名
当Host的autoDeploy或deployOnStartup属性设置为true时，Context的名称和路径来源于定义web 应用的文件的名称。因此，context的路径可能没有在web应用程序中嵌入的META-INF/context.xml中定义的情况下，Context的名称、路径、版本和定义web应用的文件的基文件名（文件名去除.war或者.xml后缀）具有紧密的联系。
如果没有版本信息，Context名称和路径总是相同的，如果Context路径为空字符串，那么基文件名为ROOT，否则基文件名为Context路径去除首个/并将后面的/替换为#。
如果具有版本信息，Context路径不变，Context名称和基文件名应在末尾添加##+版本信息。一些命名惯例如下图：

如果想要使用和基文件名无关的Context路径部署web应用，那么需要使用以下方法之一避免重复发布：
- 设置autoDeploy和 deployOnStartup为false并且在server.xml中定义Context
- 将应用程序文件夹或war包放在虚拟主机appBase目录之外，并且在context.xml中通过docBase属性指向该目录。

3）定义Context
不建议将Context元素直接定义在server.xml中，因为这使修改Context配置更有侵入性，因为不重启Tomcat的情况下无法重新加载server.xml。默认Context元素将会覆盖任何server.xml中的context元素的配置，将context元素的属性 override 设置为true可以避免。
单个web应用的Context元素可以通过如下方式定义：
- 应用程序内部独立的/META-INF/context.xml文件。根据Host元素的copyXML属性，此文件可能被复制到$CATALINA_BASE/conf/[enginename]/[hostname]/目录并且重命名为基文件名加".xml"扩展名
- $CATALINA_BASE/conf/[enginename]/[hostname]/文件夹内的独立的xml文件，Context的路径和版本来源于此文件的基文件名。此路径下的xml文件优先级高于web应用程序内部META-INF文件夹的context.xml文件
- conf/server.xml文件中Host元素内嵌入Context元素

默认Context元素可能被定义用于匹配多个web应用：
$CATALINA_BASE/conf/context.xml文件中的Context元素配置将被所有应用程序加。$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default文件中的Context元素信息将会被当前虚拟主机的所有应用程序加载。

2）属性

属性名	描述
docBase	指定应用程序的物理位置，可以是绝对路径，也可以是相对路径（相对于虚拟主机的appBase）。除非Context元素定义在server.xml中或者web应用的物理位置不在Host的appBase，否则这个属性值不能被设置。如果docBase属性值包含符号链接，当符号链接改变时，只有重启服务器或重新部署Context才能生效，重新加载Context是无效的
override	设置为true以忽略全局或主机默认context.xml中的任何设置。 默认情况下，将使用默认context.xml中的设置，但可以通过为Context明确设置相同属性来覆盖这些设置
path	设置web应用的上下文路径，用于匹配request URI来选择正确的web应用处理请求。该属性值只有在Context元素定义在server.xml中时才可能设置，其他情况将会由Context的xml配置文件名或docBase推断。即使是通过server.xml静态部署Context，只有在docBase不是Host 的appBase时或者deployOnStartup和autoDeploy 均设置为false时才设置该属性，否则可能会导致重复部署
reloadable	设置为true时Catalina将会监视 /WEB-INF/classes/ 和WEB-INF/lib 中的classes的变化，并自动重新加载应用程序，默认值为false

未完待续…