本文将通过实例，先容server.xml中各个组件的配置，并详细解释Tomcat各个核心组件的浸染以及各个组件之间的相互关系。
解释：由于server.xml文件中元素与Tomcat中组件的对应关系，后文中为了描述方便，“元素”和“组件”的利用不严格区分。
如果以为文章对你有帮助，欢迎点赞或转载。文章有疏漏之处，欢迎批评示正。
server.xml位于$TOMCAT_HOME/conf目录下；下面是一个server.xml实例。后文中将结合该实例讲解server.xml中，各个元素的含义和浸染；在阅读后续章节过程中，可以对照该xml文档便于理解。
二、server.xml文档的元素分类和整体构造
1、整体构造server.xml的整体构造如下：
该构造中只给出了Tomcat的核心组件，除了核心组件外，Tomcat还有一些其他组件，下面先容一下组件的分类。
2、元素分类server.xml文件中的元素可以分为以下4类：
（1）顶层元素：<Server>和<Service>
<Server>元素是全体配置文件的根元素，<Service>元素则代表一个Engine元素以及一组与之相连的Connector元素。
（2）连接器：<Connector>
<Connector>代表了外部客户端发送要求到特定Service的接口；同时也是外部客户端从特定Service吸收相应的接口。
（3）容器：<Engine><Host><Context>
容器的功能是处理Connector吸收进来的要求，并产生相应的相应。Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。一个Engine组件可以处理Service中的所有要求，一个Host组件可以处理发向一个特定虚拟主机的所有要求，一个Context组件可以处理一个特定Web运用的所有要求。
（4）内嵌组件：可以内嵌到容器中的组件。实际上，Server、Service、Connector、Engine、Host和Context是最主要的最核心的Tomcat组件，其他组件都可以归为内嵌组件。
下面将详细先容Tomcat中各个核心组件的浸染，以及相互之间的关系。点此查看一分钟配置tomcat的https教程。
三、核心组件本部分将分别先容各个核心组件的浸染、特点以及配置办法等。
1、ServerServer元素在最顶层，代表全体Tomcat容器，因此它必须是server.xml中唯一一个最外层的元素。一个Server元素中可以有一个或多个Service元素。
在第一部分的例子中，在最外层有一个<Server>元素，shutdown属性表示关闭Server的指令；port属性表示Server吸收shutdown指令的端口号，设为-1可以禁掉该端口。
Server的紧张任务，便是供应一个接口让客户端能够访问到这个Service凑集，同时掩护它所包含的所有的Service的声明周期，包括如何初始化、如何结束做事、如何找到客户端要访问的Service。
2、ServiceService的浸染，是在Connector和Engine表面包了一层，把它们组装在一起，对外供应做事。一个Service可以包含多个Connector，但是只能包含一个Engine；个中Connector的浸染是从客户端吸收要求，Engine的浸染是处理吸收进来的要求。
在第一部分的例子中，Server中包含一个名称为“Catalina”的Service。实际上，Tomcat可以供应多个Service，不同的Service监听不同的端口，后文会有先容。
3、ConnectorConnector的紧张功能，是吸收连接要求，创建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的https教程。
在这个例子中，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等集成的事理如下图。
关于Connector的更多内容，可以参考我的另一篇文章：详解tomcat的连接数与线程池
4、EngineEngine组件在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与HostHost是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且个中一个的name必须与Engine组件的defaultHost属性相匹配。
（2）Host的浸染Host虚拟主机的浸染，是运行多个Web运用（一个Context代表一个Web运用），并卖力安装、展开、启动和结束每个Web运用。
Host组件代表的虚拟主机，对应了做事器中一个网络名实体(如”www.javastack.cn”，或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/<engine_name>/<host_name>，例如第一部分的例子中，主机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>元素的配置
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中通过<context>元素静态支配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和EngineService中的Connector组件可以吸收特定端口的要求，因此，当Tomcat启动时，Service组件就会监听特定的端口。在第一部分的例子中，Catalina这个Service监听了8080端口（基于HTTP协议）和8009端口（基于AJP协议）。当要求进来时，Tomcat便可以根据协议和端口号选定处理要求的Service；Service一旦选定，Engine也就确定。
通过在Server中配置多个Service，可以实现通过不同的端口号来访问同一台机器上支配的不同运用。
（2）根据域名或IP地址选定HostService确定后，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）复制<Service>元素，放在当前<Service>后面。
（2）修正端口号：根据须要监听的端口号修正<Connector>元素的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的配置如下：
再将原webapps下的docs目录拷贝到webapps2中，则通过如下两个接口都可以访问docs运用：
http://localhost:8080/docs/
http://localhost:8084/docs/
五、其他组件除核心组件外，server.xml中还可以配置很多其他组件。下面只先容第一部分例子中涌现的组件，如果要理解更多内容，可以查看Tomcat官方文档。
1、ListenerListener(即监听器)定义的组件，可以在特定事宜发生时实行特定的操作；被监听的事宜常日是Tomcat的启动和停滞。
监听器可以在Server、Engine、Host或Context中，本例中的监听器都是在Server中。实际上，本例中定义的6个监听器，都只能存在于Server组件中。监听器不许可内嵌其他组件。
监听器须要配置的最主要的属性是className，该属性规定了监听器的详细实现类，该类必须实现了org.apache.catalina.LifecycleListener接口。
点此查看一分钟配置tomcat的https教程。
下面依次先容例子中配置的监听器：
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组件：
Realm，可以把它理解成“域”；Realm供应了一种用户密码与web运用的映射关系，从而达到角色安全管理的浸染。在本例中，Realm的配置利用name为UserDatabase的资源实现。而该资源在Server元素中利用GlobalNamingResources配置：
GlobalNamingResources元素定义了全局资源，通过配置可以看出，该配置是通过读取$TOMCAT_HOME/ conf/tomcat-users.xml实现的。
关于Tomcat域管理的更多内容，可以参考：Realm域管理
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，含义是要求处理的韶光(单位是毫秒)，对付统计剖析要求的处理速率帮助很大。
开拓职员可以充分利用访问日志，来剖析问题、优化运用。例如，剖析访问日志中各个接口被访问的比例，不仅可以为需求和运营职员供应数据支持，还可以使自己的优化对症下药；剖析访问日志中各个要求的相应状态码，可以知道做事器要求的成功率，并找出有问题的要求；剖析访问日志中各个要求的相应韶光，可以找出慢要求，并根据须要进行相应韶光的优化。
原文：http://www.cnblogs.com/kismetv/p/7228274.html
