前言

Tomcat隶属于Apache基金会，是开源的轻量级Web应使用服务器，用非常广泛。server.xml是Tomcat中最重要的配置文件，server.xml的每一个元素都对应了Tomcat中的一个组件；通过对xml文件中元素的配置，能实现对Tomcat中各个组件的控制。因而，学习server.xml文件的配置，对于理解和用Tomcat至关重要。

本文将通过实例，详情server.xml中各个组件的配置，并详细说明Tomcat各个核心组件的作使用以及各个组件之间的相互关系。

说明：因为server.xml文件中元素与Tomcat中组件的对应关系，后文中为了形容方便，“元素”和“组件”的用不严格区分。

一、一个server.xml配置实例

server.xml位于$TOMCAT_HOME/conf目录下；下面是一个server.xml实例。后文中将结合该实例讲解server.xml中，各个元素的含义和作使用；在阅读后续章节过程中，能对照该xml文档便于了解。

11 type="org.apache.catalina.UserDatabase"

12 description="User database that can be updated and saved"

13 factory="org.apache.catalina.users.MemoryUserDatabaseFactory"

14 pathname="conf/tomcat-users.xml" />

19 connectionTimeout="20000"

20 redirectPort="8443" />

25 resourceName="UserDatabase"/>

29 unpackWARs="true" autoDeploy="true">

31 prefix="localhost_access_log." suffix=".txt"

32 pattern="%h %l %u %t "%r" %s %b" />

二、server.xml文档的元素分类和整体结构

1、整体结构

server.xml的整体结构如下：

该结构中只给出了Tomcat的核心组件，除了核心组件外，Tomcat还有少量其余组件，下面详情一下组件的分类。

2、元素分类

server.xml文件中的元素能分为以下4类：

（1）顶层元素：和

元素是整个配置文件的根元素，元素则代表一个Engine元素以及一组与之相连的Connector元素。

（2）连接器：

代表了外部用户端发送请求到特定Service的接口；同时也是外部用户端从特定Service接收响应的接口。

（3）容器：

容器的功可以是解决Connector接收进来的请求，并产生相应的响应。Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。一个Engine组件能解决Service中的所有请求，一个Host组件能解决发向一个特定虚拟主机的所有请求，一个Context组件能解决一个特定Web应使用的所有请求。

（4）内嵌组件：能内嵌到容器中的组件。实际上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat组件，其余组件都能归为内嵌组件。

下面将详细详情Tomcat中各个核心组件的作使用，以及相互之间的关系。

三、核心组件

本部分将分别详情各个核心组件的作使用、特点以及配置方式等。

1、Server

Server元素在最顶层，代表整个Tomcat容器，因而它必需是server.xml中唯逐个个最外层的元素。一个Server元素中能有一个或者多个Service元素。

在第一部分的例子中，在最外层有一个元素，shutdown属性表示关闭Server的指令；port属性表示Server接收shutdown指令的端口号，设为-1能禁掉该端口。

Server的主要任务，就是提供一个接口让用户端可以够访问到这个Service集合，同时维护它所包含的所有的Service的公告周期，包括如何初始化、如何结束服务、如何找到用户端要访问的Service。

2、Service

Service的作使用，是在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service能包含多个Connector，但是只可以包含一个Engine；其中Connector的作使用是从用户端接收请求，Engine的作使用是解决接收进来的请求。

在第一部分的例子中，Server中包含一个名称为“Catalina”的Service。实际上，Tomcat能提供多个Service，不同的Service监听不同的端口，后文会有详情。

3、Connector

Connector的主要功可以，是接收连接请求，创立Request和Response对象使用于和请求端交换数据；而后分配线程让Engine来解决这个请求，并把产生的Request和Response对象传给Engine。

通过配置Connector，能控制请求Service的协议及端口号。在第一部分的例子中，Service包含两个Connector：

（1）通过配置第1个Connector，用户端能通过8080端口号用http协议访问Tomcat。其中，protocol属性规定了请求的协议，port规定了请求的端口号，redirectPort表示当强制要求https而请求是http时，重定向至端口号为8443的Connector，connectionTimeout表示连接的超时时间。

在这个例子中，Tomcat监听HTTP请求，用的是8080端口，而不是正式的80端口；实际上，在正式的生产环境中，Tomcat也常常监听8080端口，而不是80端口。这是由于在生产环境中，很少将Tomcat直接对外开放接收请求，而是在Tomcat和用户端之间加一层代理商服务器(如nginx)，使用于请求的转发、负载均衡、解决静态文件等；通过代理商服务器访问Tomcat时，是在局域网中，因而一般仍用8080端口。

（2）通过配置第2个Connector，用户端能通过8009端口号用AJP协议访问Tomcat。AJP协议负责和其余的HTTP服务器(如Apache)建立连接；在把Tomcat与其余HTTP服务器集成时，就需要使用到这个连接器。之所以用Tomcat和其余服务器集成，是由于Tomcat能使用作Servlet/JSP容器，但是对静态资源的解决速度较慢，不如Apache和IIS等HTTP服务器；因而常常将Tomcat与Apache等集成，前者作Servlet容器，后者解决静态资源，而AJP协议便负责Tomcat和Apache的连接。Tomcat与Apache等集成的原理如下图：

4、Engine

Engine组件在Service组件中有且只有一个；Engine是Service组件中的请求解决组件。Engine组件从一个或者多个Connector中接收请求并解决，并将完成的响应返回给Connector，最终传递给用户端。

前面已经提到过，Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。

在第一部分的例子中，Engine的配置语句如下：

其中，name属性使用于日志和错误信息，在整个Server中应该唯一。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，全部用defaultHost指定的host进行解决；因而，defaultHost的值，必需与Engine中的一个Host组件的name属性值匹配。

5、Host

（1）Engine与Host

Host是Engine的子容器。Engine组件中能内嵌1个或者多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必需与Engine组件的defaultHost属性相匹配。

（2）Host的作使用

Host虚拟主机的作使用，是运行多个Web应使用（一个Context代表一个Web应使用），并负责安装、开展、启动和结束每个Web应使用。

Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如”www.test.com”，或者IP地址”116.25.25.25”)；为了用户能通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。

用户端通常用主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻觅名称匹配的主机。假如没有匹配，请求将发送至默认主机。因而默认主机不需要是在DNS服务器中注册的网络名，由于任何与所有Host名称不匹配的请求，都会路由至默认主机。

（3）Host的配置

在第一部分的例子中，Host的配置如下：

下面对其中配置的属性进行说明：

name属性指定虚拟主机的主机名，一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；一般情况下，主机名需要是在DNS服务器中注册的网络名，但是Engine指定的defaultHost不需要，起因在前面已经说明。

unpackWARs指定了能否将代表Web应使用的WAR文件解压；假如为true，通过解压后的文件结构运行该Web应使用，假如为false，直接用WAR文件运行Web应使用。

Host的autoDeploy和appBase属性，与Host内Web应使用的自动部署有关；此外，本例中没有出现的xmlBase和deployOnStartup属性，也与Web应使用的自动部署有关；将在下一节(Context)中详情。

6、Context

（1）Context的作使用

Context元素代表在特定虚拟主机上运行的一个Web应使用。在后文中，提到Context、应使用或者Web应使用，它们指代的都是Web应使用。每个Web应使用基于WAR文件，或者WAR文件解压后对应的目录（这里称为应使用目录）。

Context是Host的子容器，每个Host中能定义任意多的Context元素。

在第一部分的例子中，能看到server.xml配置文件中并没有出现Context元素的配置。这是由于，Tomcat开启了自动部署，Web应使用没有在server.xml中配置静态部署，而是由Tomcat通过特定的规则自动部署。下面详情一下Tomcat自动部署Web应使用的机制。

（2）Web应使用自动部署

Host的配置

要开启Web应使用的自动部署，需要配置所在的虚拟主机；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。假如deployOnStartup和autoDeploy设置为true，则tomcat启动自动部署：当检测到新的Web应使用或者Web应使用的升级时，会触发应使用的部署(或者重新部署)。二者的主要区别在于，deployOnStartup为true时，Tomcat在启动时检查Web应使用，且检测到的所有Web应使用视作新应使用；autoDeploy为true时，Tomcat在运行时定期检查新的Web应使用或者Web应使用的升级。除此之外，二者的解决类似。

通过配置deployOnStartup和autoDeploy能开启虚拟主机自动部署Web应使用；实际上，自动部署依赖于检查能否有新的或者更改过的Web应使用，而Host元素的appBase和xmlBase设置了检查Web应使用升级的目录。

其中，appBase属性指定Web应使用所在的目录，默认值是webapps，这是一个相对路径，代表Tomcat根目录下webapps文件夹。

xmlBase属性指定Web应使用的XML配置文件所在的目录，默认值为conf//，例如第一部分的例子中，主机localhost的xmlBase的默认值是$TOMCAT_HOME/conf/Catalina/localhost。

检查Web应使用升级

一个Web应使用可可以包括以下文件：XML配置文件，WAR包，以及一个应使用目录(该目录包含Web应使用的文件结构)；其中XML配置文件位于xmlBase指定的目录，WAR包和应使用目录位于appBase指定的目录。

Tomcat按照如下的顺序进行扫描，来检查应使用升级：

A、扫描虚拟主机指定的xmlBase下的XML配置文件

B、扫描虚拟主机指定的appBase下的WAR文件

C、扫描虚拟主机指定的appBase下的应使用目录

元素的配置

Context元素最重要的属性是docBase和path，此外reloadable属性也比较常使用。

docBase指定了该Web应使用用的WAR包路径，或者应使用目录。需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定；假如docBase指定的WAR包或者应使用目录就在docBase中，则不需要指定，由于Tomcat会自动扫描appBase中的WAR包和应使用目录，指定了反而会造成问题。

path指定了访问该Web应使用的上下文路径，当请求到来时，Tomcat根据Web应使用的 path属性与URI的匹配程度来选择Web应使用解决相应请求。例如，Web应使用app1的path属性是”/app1”，Web应使用app2的path属性是”/app2”，那么请求/app1/index.html会交由app1来解决；而请求/app2/index.html会交由app2来解决。假如一个Context元素的path属性为””，那么这个Context是虚拟主机的默认Web应使用；当请求的uri与所有的path都不匹配时，用该默认Web应使用来解决。

但是，需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，不可以指定path属性，path属性由配置文件的文件名、WAR文件的文件名或者应使用目录的名称自动推导出来。如扫描Web应使用时，发现了xmlBase目录下的app1.xml，或者appBase目录下的app1.WAR或者app1应使用目录，则该Web应使用的path属性是”app1”。假如名称不是app1而是ROOT，则该Web应使用是虚拟主机默认的Web应使用，此时path属性推导为””。

reloadable属性指示tomcat能否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。假如值为true，那么当class文件改动时，会触发Web应使用的重新加载。在开发环境下，reloadable设置为true便于调试；但是在生产环境中设置为true会给服务器带来性可以压力，因而reloadable参数的默认值为false。

下面来看自动部署时，xmlBase下的XML配置文件app1.xml的例子：

在该例子中，docBase位于Host的appBase目录之外；path属性没有指定，而是根据app1.xml自动推导为”app1”；因为是在开发环境下，因而reloadable设置为true，便于开发调试。

自动部署举例

最典型的自动部署，就是当我们安装完Tomcat后，$TOMCAT_HOME/webapps目录下有如下文件夹：

当我们启动Tomcat后，能用http://localhost:8080/来访问Tomcat，其实访问的就是ROOT对应的Web应使用；我们也能通过http://localhost:8080/docs来访问docs应使用，同理我们能访问examples/host-manager/manager这几个Web应使用。

（3）server.xml中静态部署Web应使用

除了自动部署，我们也能在server.xml中通过元素静态部署Web应使用。静态部署与自动部署是能共存的。在实际应使用中，并不推荐用静态部署，由于server.xml 是不可动态重加载的资源，服务器一旦启动了以后，要修改这个文件，就得重启服务器才可以重新加载。而自动部署能在Tomcat运行时通过定期的扫描来实现，不需要重启服务器。

server.xml中用Context元素配置Web应使用，Context元素应该位于Host元素中。举例如下：

docBase：静态部署时，docBase能在appBase目录下，也能不在；本例中，docBase不在appBase目录下。

path：静态部署时，能显式指定path属性，但是依然受到了严格的限制：只有当自动部署完全关闭(deployOnStartup和autoDeploy都为false)或者docBase不在appBase中时，才能设置path属性。在本例中，docBase不在appBase中，因而path属性能设置。

reloadable属性的使用法与自动部署时相同。

四、核心组件的关联

1、整体关系

核心组件之间的整体关系，在上一部分有所详情，这里总结一下：

Server元素在最顶层，代表整个Tomcat容器；一个Server元素中能有一个或者多个Service元素。

Service在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service能包含多个Connector，但是只可以包含一个Engine；Connector接收请求，Engine解决请求。

Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每个Host组件代表Engine中的一个虚拟主机；每个Context组件代表在特定Host上运行的一个Web应使用。

2、如何确定请求由谁解决？

当请求被发送到Tomcat所在的主机时，如何确定最终哪个Web应使用来解决该请求呢？

（1）根据协议和端口号选定Service和Engine

Service中的Connector组件能接收特定端口的请求，因而，当Tomcat启动时，Service组件就会监听特定的端口。在第一部分的例子中，Catalina这个Service监听了8080端口（基于HTTP协议）和8009端口（基于AJP协议）。当请求进来时，Tomcat便能根据协议和端口号选定解决请求的Service；Service一旦选定，Engine也就确定。

通过在Server中配置多个Service，能实现通过不同的端口号来访问同一台机器上部署的不同应使用。

（2）根据域名或者IP地址选定Host

Service确定后，Tomcat在Service中寻觅名称与域名/IP地址匹配的Host解决该请求。假如没有找到，则用Engine中指定的defaultHost来解决该请求。在第一部分的例子中，因为只有一个Host（name属性为localhost），因而该Service/Engine的所有请求都交给该Host解决。

（3）根据URI选定Context/Web应使用

这一点在Context一节有详细的说明：Tomcat根据应使用的 path属性与URI的匹配程度来选择Web应使用解决相应请求，这里不再赘述。

（4）举例

以请求http://localhost:8080/app1/index.html为例，首先通过协议和端口号（http和8080）选定Service；而后通过主机名（localhost）选定Host；而后通过uri（/app1/index.html）选定Web应使用。

3、如何配置多个服务

通过在Server中配置多个Service服务，能实现通过不同的端口号来访问同一台机器上部署的不同Web应使用。

在server.xml中配置多服务的方法非常简单，分为以下几步：

（1）复制元素，放在当前后面。

（2）修改端口号：根据需要监听的端口号修改元素的port属性；必需确保该端口没有被其余进程占使用，否则Tomcat启动时会报错，而无法通过该端口访问Web应使用。

以Win7为例，能使用如下方法找出某个端口能否被其余进程占使用：netstat -aon|findstr "8081"发现8081端口被PID为2064的进程占使用，tasklist |findstr "2064"发现该进程为FrameworkService.exe(这是McAfee杀毒软件的进程)。

（3）修改Service和Engine的name属性

（4）修改Host的appBase属性（如webapps2）

（5）Web应使用依然用自动部署

（6）将要部署的Web应使用(WAR包或者应使用目录)拷贝到新的appBase下。

以第一部分的server.xml为例，多个Service的配置如下：

1 <?xml version='1.0' encoding='utf-8'?>

20 resourceName="UserDatabase"/>

35 resourceName="UserDatabase"/>

再将原webapps下的docs目录拷贝到webapps2中，则通过如下两个接口都能访问docs应使用：

http://localhost:8080/docs/

http://localhost:8084/docs/

五、其余组件

除核心组件外，server.xml中还能配置很多其余组件。下面只详情第一部分例子中出现的组件，假如要理解更多内容，能查看Tomcat官方文档。

1、Listener

Listener(即监听器)定义的组件，能在特定事件发生时执行特定的操作；被监听的事件通常是Tomcat的启动和中止。

监听器能在Server、Engine、Host或者Context中，本例中的监听器都是在Server中。实际上，本例中定义的6个监听器，都只可以存在于Server组件中。监听器不允许内嵌其余组件。

监听器需要配置的最重要的属性是className，该属性规定了监听器的具体实现类，该类必需实现了org.apache.catalina.LifecycleListener接口。

下面依次详情例子中配置的监听器：

VersionLoggerListener：当Tomcat启动时，该监听器记录Tomcat、Java和操作系统的信息。该监听器必需是配置的第一个监听器。
AprLifecycleListener：Tomcat启动时，检查APR库，假如存在则加载。APR，即Apache Portable Runtime，是Apache可移植运行库，能实现高可扩展性、高性可以，以及与本地服务器技术更好的集成。
JasperListener：在Web应使用启动之前初始化Jasper，Jasper是JSP引擎，把JVM不认识的JSP文件解析成java文件，而后编译成class文件供JVM用。
JreMemoryLeakPreventionListener：与类加载器导致的内存泄露有关。
GlobalResourcesLifecycleListener：通过该监听器，初始化< GlobalNamingResources>标签中定义的全局JNDI资源；假如没有该监听器，任何全局资源都不可以用。< GlobalNamingResources>将在后文详情。
ThreadLocalLeakPreventionListener：当Web应使用因thread-local导致的内存泄露而要中止时，该监听器会触发线程池中线程的升级。当线程执行完任务被收回线程池时，活跃线程会一个一个的升级。只有当Web应使用(即Context元素)的renewThreadsWhenStoppingContext属性设置为true时，该监听器才有效。

2、GlobalNamingResources与Realm

第一部分的例子中，Engine组件下定义了Realm组件：

3 resourceName="UserDatabase"/>

Realm，能把它了解成“域”；Realm提供了一种使用户密码与web应使用的映射关系，从而达到角色安全管理的作使用。在本例中，Realm的配置用name为UserDatabase的资源实现。而该资源在Server元素中用GlobalNamingResources配置：

GlobalNamingResources元素定义了全局资源，通过配置能看出，该配置是通过读取$TOMCAT_HOME/ conf/tomcat-users.xml实现的。

3、Valve

在第一部分的例子中，Host元素内定义了Valve组件：

单词Valve的意思是“阀门”，在Tomcat中代表了请求解决流水线上的一个组件；Valve能与Tomcat的容器(Engine、Host或者Context)关联。

不同的Valve有不同的特性，下面详情一下本例中出现的AccessLogValve。

AccessLogValve的作使用是通过日志记录其所在的容器中解决的所有请求，在本例中，Valve放在Host下，便能记录该Host解决的所有请求。AccessLogValve记录的日志就是访问日志，每天的请求会写到一个日志文件里。AccessLogValve能与Engine、Host或者Context关联；在本例中，只有一个Engine，Engine下只有一个Host，Host下只有一个Context，因而AccessLogValve放在三个容器下的作使用其实是相似的。

本例的AccessLogValve属性的配置，用的是默认的配置；下面详情AccessLogValve中各个属性的作使用：

（1）className：规定了Valve的类型，是最重要的属性；本例中，通过该属性规定了这是一个AccessLogValve。

（2）directory：指定日志存储的位置，本例中，日志存储在$TOMCAT_HOME/logs目录下。

（3）prefix：指定了日志文件的前缀。

（4）suffix：指定了日志文件的后缀。通过directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目录下，能看到如下所示的日志文件。

（5）pattern：指定记录日志的格式，本例中各项的含义如下：

%h：远程主机名或者IP地址；假如有nginx等反向代理商服务器进行请求分发，该主机名/IP地址代表的是nginx，否则代表的是用户端。后面远程的含义与之相似，不再解释。
%l：远程逻辑使用户名，全部是”-”，能忽略。
%u：受权的远程使用户名，假如没有，则是”-”。
%t：访问的时间。
%r：请求的第一行，即请求方法(get/post等)、uri、及协议。
%s：响应状态，200,404等等。
%b：响应的数据量，不包括请求头，假如为0，则是””-。

例如，下面是访问日志中的一条记录

pattern的配置中，除了上述各项，还有一个非常常使用的选项是%D，含义是请求解决的时间(单位是毫秒)，对于统计分析请求的解决速度帮助很大。

开发人员能充分利使用访问日志，来分析问题、优化应使用。例如，分析访问日志中各个接口被访问的比例，不仅能为需求和经营人员提供数据支持，还能使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，能知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，能找出慢请求，并根据需要进行响应时间的优化。