Tomcat配置项目路径以及配置多项目

野性酷女 2022-05-21 01:18 310阅读 0赞

这个是之前一个tomcat里带了几个项目的配置，单独的也可以按照这个配，根据自己情况。希望看到的同学有所收获 :)

先上配置，有需要的同学可以借鉴。

以上  
按照此配置我们直接把opz.war包放在/data/code/task/下直接启动tomcat就能访问了

最简单的发布，不配置任何tomcat，直接把项目解压到webapp下面的ROOT目录启动tomcat即可。

如果只配置appBase，不配Context 的docBase，那appBase下的每个文件夹都代表一个目录，里面必须包含ROOT文件，ROOT里是web项目的文件：

> /data/code/task/opz/ROOT/web项目文件

appBase,下面的每个子目录将自动被部署为应用。如果有war包则会自动解压部署，如果war内是ROOT文件可以访问，没有就访问不到，需要docBase配置。docBase指向的是应用目录，可以和appBase结合起来，指向其内的项目，亦可以单独配置。

> 如果你把他们弄重复了，也就是2个指向了一个目录，看上去也能运行，但你的应用下面的每个子目录，其实是被部署为单独的应用的。  
> 比如你的应用为  
> myApp, 放在了  
> d:\\project\\myApp  
> 里面有2个子目录  
> d:\\project\\myApp\\images  
> d:\\project\\myApp\\js  
> 你可以通过  
> 1 设置 appBase 指向 d:\\project 来让系统自动部署  
> 2 你可以手工指定docBase到 d:\\project\\myApp  
> 3 如果你指定了 appBase到 d:\\project\\myApp 那么  
> d:\\project\\myApp\\images这个将不再是普通的子目录，而是一个单独的虚拟目录，或者叫应用了。因为其被自动部署  
> d:\\project\\myApp\\js 也一样的后果  
> 关于tomcat配置多项目：  
> 在tomcat配置文件下，每个项目添加一个service

通过配置第1个Connector，客户端可以通过8080端口号使用http协议访问Tomcat。其中，protocol属性规定了请求的协议，port规定了请求的端口号，redirectPort表示当强制要求https而请求是http时，重定向至端口号为8443的Connector，connectionTimeout表示连接的超时时间。  
通过配置第2个Connector，客户端可以通过8009端口号使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要用到这个连接器。之所以使用Tomcat和其他服务器集成，是因为Tomcat可以用作Servlet/JSP容器，但是对静态资源的处理速度较慢，不如Apache和IIS等HTTP服务器；因此常常将Tomcat与Apache等集成，前者作Servlet容器，后者处理静态资源，而AJP协议便负责Tomcat和Apache的连接。

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

Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。  
Host虚拟主机的作用，是运行多个Web应用（一个Context代表一个Web应用），并负责安装、展开、启动和结束每个Web应用。  
Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如”www.test.com”，或IP地址”116.25.25.25”)；为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。但是Engine指定的defaultHost不需要。

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

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

**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。

`<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。