tomcat服务器的l配置详解
tomcat是⼀个开源的轻量级WEB应⽤服务器
⼀：
1、最外层是<server></server>元素，<server>元素是l的根元素，其属性shutdown表⽰关闭serverd的指令；port属性表⽰server接收shutdown指令的端⼝号，设为-1可以禁掉该端⼝。总的来说意思就是，使tomcat监听8005端⼝，如果使⽤telnet连接8005端⼝并输⼊SHUTDOWN，则tomcat就会关闭。Server的主要任务，就是提供⼀个接⼝让客户端能够访问到这个Service集合，同时维护它所包含的所有的Service的声明周期，包括如何初始化、如何结束服务、如何到客户端要访问的Service。
2、<server>下边是<service>元素（可以有多个），Service的作⽤，是在Connector和Engine外⾯包了⼀层，把它们组装在⼀起，对外提供服务。
3、<service>元素下是<Connector>和<Engine>元素
Connector的主要功能，是接收连接请求，创建Request和Response对象⽤于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产⽣的Request和Response对象传给Engine。通过配置Connector，可以控制请求Service的协议及端⼝号。
（1）通过配置第1个Connector，客户端可以通过8080端⼝号使⽤http协议访问Tomcat。其中，protocol属性规定了请求的协议，port 规定了请求的端⼝号，redirectPort表⽰当强制要求https⽽请求是http时，重定向⾄端⼝号为8443的Connector，connectionTimeout 表⽰连接的超时时间。
（2）通过配置第2个Connector，客户端可以通过8009端⼝号使⽤AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建⽴连接；在把Tomcat与其他HTTP服务器集成时，就需要⽤到这个连接器。之所以使⽤Tomcat和其他服务器集成，是因为Tomcat可以⽤作Servlet/JSP容器，但是对静态资源的处理速度较慢，不如Apache和IIS等HTTP服务器；因此常常将Tomcat与Apache 等集成，前者作Servlet容器，后者处理静态资源，⽽AJP协议便负责Tomcat和Apache的连接。
Engine组件在Service组件中有且只有⼀个；Engine是Service组件中的请求处理组件。Engine组件从⼀个或多个Connector中接收请求并处理，并将完成的响应返回给Connector，最终传递给客户端。
其中，name属性⽤于⽇志和错误信息，在整个Server中应该唯⼀。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，⼀律使⽤defaultHost指定的host进⾏处理；因此，defaultHost的值，必须与Engine中的⼀个Host组件的name属性值匹配。
网络上xml是什么意思4、<Engine>元素下边是<Realm>、<Host>元素
Host是Engine的⼦容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的⼀个虚拟主机。Host组件⾄少有⼀个，且其中⼀个的name必须与Engine组件的defaultHost属性相匹配。作⽤是运⾏多个Web应⽤（⼀个Context代表⼀个Web应⽤），并负责安装、展开、启动和结束每个Web应⽤。
Host组件代表的虚拟主机，对应了服务器中⼀个⽹络名实体(如”www.javastack”，或IP地址”116.25.25.25”)；为了使⽤户可以通过⽹络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。
客户端通常使⽤主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻名称匹配的主机。如果没有匹配，请求将发送⾄默认主机。因此默认主机不需要是在DNS服务器中注册的⽹络名，因为任何与所有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应⽤的⾃动部署有关；
5、<Host>元素下有<Valve>、<Context>元素
Context元素代表在特定虚拟主机上运⾏的⼀个Web应⽤。在后⽂中，提到Context、应⽤或Web应⽤，它们指代的都是Web应⽤。每个Web应⽤基于WAR⽂件，或WAR⽂件解压后对应的⽬录（这⾥称为应⽤⽬录）。
Context是Host的⼦容器，每个Host中可以定义任意多的Context元素。
实例中配置了Context元素是因为此项⽬配置了静态部署，如果tomcat开启了⾃动部署，则不需要配置Context。
⼆：Tomcat⾃动部署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⽬录下的l，或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。
除了⾃动部署，我们也可以在l中通过<context>元素静态部署Web应⽤。静态部署与⾃动部署是可以共存的。在实际应⽤中，并不推荐使⽤静态部署，因为l 是不可动态重加载的资源，服务器⼀旦启动了以后，要修改这个⽂件，就得重启服务器才能重新加载。⽽⾃动部署可以在Tomcat运⾏时通过定期的扫描来实现，不需要重启服务器。
三：
核⼼组件的关联
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）举例
3、如何配置多个服务
通过在Server中配置多个Service服务，可以实现通过不同的端⼝号来访问同⼀台机器上部署的不同Web应⽤。
在l中配置多服务的⽅法⾮常简单，分为以下⼏步：
（1）复制<Service>元素，放在当前<Service>后⾯。
（2）修改端⼝号：根据需要监听的端⼝号修改<Connector>元素的port属性；必须确保该端⼝没有被其他进程占⽤，否则Tomcat启动时会报错，⽽⽆法通过该端⼝访问Web应⽤。
（3）修改Service和Engine的name属性
（4）修改Host的appBase属性
（5）Web应⽤仍然使⽤⾃动部署
（6）将要部署的Web应⽤(WAR包或应⽤⽬录)拷贝到新的appBase下。
四：其他组件
除核⼼组件外，l中还可以配置很多其他组件。下⾯只介绍第⼀部分例⼦中出现的组件，如果要了解更多内容，可以查看Tomcat 官⽅⽂档。
1、Listener
Listener(即)定义的组件，可以在特定事件发⽣时执⾏特定的操作；被监听的事件通常是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/ l实现的。
关于Tomcat域管理的更多内容，可以参考：Realm域管理
3、Valve
在第⼀部分的例⼦中，Host元素内定义了Valve组件：
单词Valve的意思是“阀门”，在Tomcat中代表了请求处理流⽔线上的⼀个组件；Valve可以与Tomcat的容器(Engine、Host或Context)关联。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。