这个是之前一个tomcat里带了几个项目的配置,单独的也可以按照这个配,根据自己情况。希望看到的同学有所收获 :)
先上配置,有需要的同学可以借鉴。
<Service name="servicename">
<Connector port="8087" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="servicename" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
Realm>
<Host name="localhost" appBase="/data/code/task/"
unpackWARs="true" autoDeploy="true">
<Context path="/" docBase="/data/code/task/opz" reloadable="true" />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_task6_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
Host>
Engine>
Service>
Server>
以上
按照此配置我们直接把opz.war包放在/data/code/task/下直接启动tomcat就能访问了
最简单的发布,不配置任何tomcat,直接把项目解压到webapp下面的ROOT目录启动tomcat即可。
如果只配置appBase,不配Context 的docBase,那appBase下的每个文件夹都代表一个目录,里面必须包含ROOT文件,ROOT里是web项目的文件:
/data/code/task/opz/ROOT/web项目文件
<Host name="localhost" appBase="/data/code/task/"
unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_task6_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
Host>
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
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
通过配置第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的连接。
<Engine name="Catalina" defaultHost="localhost">
其中,name属性用于日志和错误信息,在整个Server中应该唯一。defaultHost属性指定了默认的host名称,当发往本机的请求指定的host名称不存在时,一律使用defaultHost指定的host进行处理;因此,defaultHost的值,必须与Engine中的一个Host组件的name属性值匹配。
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
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元素最重要的属性是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。