Tomcat配置文件server.xml解析

目录

• 概述
• 顶层元素（Top Level Elements）
• • 1. Server
  • 2. Service
• 线程池（Eecutors）
• • 1. Executor
• 连接器（Connectors）
• • 1. Http/1.1 Connector
• 容器（Containers）
• • 1. Engine
  • 2. Host
  • 3. Context

概述

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）公共属性

2. Service

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

2）公共属性

线程池（Eecutors）

1. Executor

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

2）公共属性

连接器（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）公共属性

容器（Containers）

1. Engine

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

2）公共属性

2. Host

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

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

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

2）公共属性

2）标准实现属性

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）属性

未完待续…