Tomcat基础(2)

Tomcat服务器的配置主要集中于tomcat/conf下的catalina.policy, catalina.properties,context.xml、server.xml、tomcat-users.xml、web.xml文件。

server.xml 是tomcat服务器的核心配置文件,包含了Tomcat的servlet容器(catalina)的所有配置。由于配置的属性特别多,我们在这里主要讲解其中的一部分重要配置。

Server是server.xml的根元素,用于创建一个Server实例,默认使用的实现类是org.apache.catalina.core.standardserver.

port:Tomcat监听的关闭服务器的端口。

shutdown:关闭服务器的指令字符串。

Server内嵌的子元素为Listener, GlobalNamingResources, Service.

默认配置的5个Listener的含义

GlobalNamingResources中定义了全局命名服务

该元素用于创建Service实例,默认使用org.apache.catalina.core.Standardservice,默认情况下,Tomcat仅指定了Service的名称,值为"Catalina",Service可以内嵌的元素为:Listener, Executor, connector, Engine ,其中Listener用于为Service添加生命周期监听器,Executor用于配置Service共享线程池,Connector用于配置Service包含的链接器,Engine用于配置Service中链接器对应的Servlet容器引擎。一个Server服务器,可以包含多个Service服务。

默认情况下Service并未添加共享线程池配置，如果我们想添加一个线程池，可以在下添加如下配置：

属性说明

属性含义

name线程池名称，用于Connector中指定。

nameprefix所创建的每个线程的名称前缀,一个单独的线程名称为namePrefix+threadNumber.

maxThreads池中最大线程数。

minSpareThreads活跃线程数,也就是核心池线程数,这些线程不会被销毁,会一直存在。

maxIdleTime线程空闲时间,超过该时间后,空闲线程会被销毁,默认值为6000 (1分钟) ,单位毫秒。

maxQueuesize在被执行前最大线程排队数目,默认为Int的最大值,也就是广义的无限。除非特殊情况,这个值不需要更改,否则会有请求不会被处理的情况发生。

prestartminSpareThreads启动线程池时是否启动minSpareThreads部分线程。默认值为false,即不启动。

threadPriority线程池中线程优先级,默认值为5,值从1到10。

className

线程池实现类,未指定情况下，默认实现类为org.apache.catalina.core.standardThreadExecutor,如果想使用自定义线程池首先需要实现  org.apache.catalina.Executor接口。

JDK工具jconsole.exe观察线程池被创建

如果不配置共享线程池，那么Catalina各组件在用到线程池时会独立创建。

Connector用于创建链接器实例。默认情况下, server.xml配置了两个链接器,一个支持HTTP协议,一个支持AJP协议。因此大多数情况下,我们并不需要新增链接器配置,只是根据需要对已有链接器进行优化。

属性说明

1) port:端口号,Connector用于创建服务端Socket并进行监听,以等待客户端请求链接。如果该属性设置为0,Tomcat将会随机选择一个可用的端口号给当前Connector使用。

2)protocol :当前Connector支持的访问协议。默认为HTTP/1.1 ,并采用自动切换机制选择一个基于JAVA NIO的链接器或者基于本地APR的链接器(根据本地是否含有Tomcat的本地库判定)。

如果不希望采用上述自动切换的机制,而是明确指定协议,可以使用以下值。

Http协议:

AJP协议

3) connectionTimeOut: Connector接收链接后的等待超时时间,单位为毫秒。-1表示不超时。

4)redirectPort:当前Connector不支持SSL(HTTP协议证书)请求,接收到了一个请求,并且也符合security-constraint约束,需要SSL传输,Catalina自动将请求重定向到指定的端口。

5)executor:指定共享线程池的名称, 也可以通过maxThreads, minSpareThreads等属性配置内部线程池。

6)URIEncoding:用于指定编码URI的字符编码,

Tomcat8.x版本默认的编码为UTF-8，Tomcat7.X版本默认为ISO-8859-1(解决请求字符串乱码问题，Tomcat8版本默认UTF-8不需要指定URI字符编码)。

完整的配置如下:

Engine作为Servlet引擎的顶级元素，内部可嵌入：Cluster、Listener、Realm、Valve和Host。

属性说明：

1)name：用于指定Engine的名称，默认为Catalina。该名称会影响一部分Tomcat的存储路径(如临时文件)

2)defaultHost：默认使用虚拟主机名称，当客户端请求指向的的主机无效时将交由默认虚拟主机处理，默认为localhost。

Host元素用于配置一个虚拟主机,它支持以下嵌入元素:Alias,cluster,Listener,valve,Realm,context,如果在Engine下配置Realm,那么此配置将在当前Engine下的所有Host中共享。同样,如果在Host中配置Realm , 则在当前Host下的所有context中共享。Context中的Realm优先级>Host的Realm优先级>Engine中的Realm优先级。

属性说明:

1)name:当前Host通用的网络名称,必须与DNS服务器上的注册信息一致。Engine中包含的Host必须存在一个名称与Engine的defaultHost设置一致。

2)appBase:当前Host的应用基础目录,当前Host上部署的web应用均在该目录下(可以是绝对目录,相对路径)。默认为webapps。

3)unpackWARs:设置为true, Host在启动时会将appBase目录下war包解压为目录。设置为false,Host将直接从war文件启动。

4)autoDeploy:控制tomcat是否在运行时定期检测并自动部署新增或变更的web应用。

通过给Host添加别名，我们可以实现同一个Host拥有多个网络名称，配置如下：

Context用于配置一个web应用，默认配置如下：

属性描述 ：

1)docBase：Web应用目录或War包的部署路径。可以是绝对路径，也可以是相对于Host appBase的相对路径。

2)Path：Web应用的Context路径。如果我们Host名为localhost，则该web应用访问的路径为： http://localhost:8080/myApp

它支持的内嵌元素为:CookieProcessor,Loader,Manager,Realm,Resources,WatchedResource,Jarscanner,Valve.

该配置文件中，主要配置的是Tomcat的用户，角色等信息，用来控制Tomcat中manager，host-manager的访问权限。

web.xml是web应用的描述文件, 它支持的元素及属性来自于servlet规范定义。在Tomcat中,web应用的描述信息包括tomcat/conf/web.xml中默认配置以及web应用WEB-INE/web.xml下的定制配置。

我们可以通过<context-param>添加ServletContext初始化参数，它配置了一个键值对，这样我们可以在应用程序中使用javax.servlet.ServletContext.getInitParameter()方法获取参数。 可以直接在servlet中进行应用 。

5.2 会话配置

<session-config>用于配置web应用会话，包括超时时间Cookie配置以及 会话追踪模式 。它将覆盖server.xml和context.xml

1)session-timeout:超时时间,单位分钟。

2)cookie-config:用于配置会话追踪Cookie

nane:Cookie的名称

domain:Cookie的域名

path: Cookie的路径

comment: 注释

http-only:cookie只能通过HTTP方式进行访问, JS无法读取或修改,此项可以增加网站访问的安全性。

secuze :设置true则此cookie只能通过HTTPS连接传递到服务器,而HTTP连接则不会传递该信息。注意是从浏览器传递到服务器,服务器端的Cookie对像不受此项影响。

max-age:以秒为单位表示cookie的生存期,默认为-1表示是会话Cookie ,浏览器关闭时就会消失。

3)tracking-mode:用于配置会话追踪模式,Servlet3.0版本中支持追踪模式:COOKIE,URL,SSL

ACOOKIE:通过HTTP Cookie 追踪会话是最常用的会话追踪机制, 而且Servlet规范也要求所有的Servlet规范都需要支持Cookie追踪。

B.URL:URL重写是最基本的会话追踪机制。当客户端不支持Cookie时,可以采用URI重写的方式。当采用URI追踪模式时,请求路径需要包含会话标识信息,Servlet容器会根据路径中的会话标识设置请求的会话信息。如:"http: //www.myserver.com/user/index.htmljessionid=1234567890。

C.SSL:对于SSL请求,通过SSL会话标识确定请求会话标识。

Servlet的配置主要是两部分，servlet和servlet-mapping；

配置说明：

1)sexvlet-name:指定servle的名称,该属性在web.xml中唯一。

2)servlet-class:用于指定servlet类名

3)init-param:用于指定servlet的初始化参数, 在应用中可以通过HttpServlet.getInitParameter获取。

4) load-on-startup:用于控制在Web应用启动时,Servlet的加载顺序。值小于0, web应用启动时,不加载该servlet,第一次访问时加载

5)enabled: true ,false。若为false ,表示servlet不处理任何请求。

6)url-pattern:用于指定URL表达式,一个servlet-mapping可以同时配置多个url-pattern。

Servlet 中文件上传配置

配置说明：

1)location:存放生成的文件地址。

2) max-file-size:允许上传的文件最大值。默认值为-1,表示没有限制。

3)max-request-size:针对该multi/form-data请求的最大数量,默认值为-1,表示无限制。

4)file-size-threshold:当数量量大于该值时, 内容会被写入文件。

Listener用于监听servlet中的事件，例如context、request、session对象的创建、修改、删除，并触发响应响应。Listener是 观察者模式 的 实现 ，在servlet中主要用于context、request、session对象的生命周期进行监控。在servlet 2.5规范中共定义了8重Listener。在启动时，ServletContextListener的执行顺序与web.xml中的配置顺序一致，停止时执行顺序相反。

配置说明：

1)filter-name:用于指定过滤器名称,在web.xm1中,过滤器名称必须唯一。

2)filter-class:过滤器的全限定类名,该类必须实现Filter接口。

3)async-supported:该过滤器是否支持异步。

4)init-param:用于配置Filter的初始化参数,可以配置多个,可以通过 FilterConfig.getInitParameter 获取

5)url-pattern:指定该过滤器需要拦截的URL。

Tomcat conf/web.xml中配置了web默认访问页面。

Tomcat启动后会尝从上到下的请求顺序。

如果在项目的WEB-INF目录下的web.xml中配置访问页面，则会覆盖Tomcat中的默认配置。

error-page用于配置web项目访问异常时定向的页面，支持HTTP响应码和异常类两种形式。优化用户体验，保证系统安全。

Tomcat中自定义错误页面放入ROOT目录下。

项目中将错误页面放在web目录下，并且会覆盖Tomcat中的配置。

从早期的Tomcat版本开始,就提供了web版的管理控制台,他们是两个独立的web应用,位于webapps目录下。Tomcat提供的管理应用有用于管理的Host的host-manager和用于管理web应用的manager。

这两个web应用主要作用就是为Tomcat提供了管理后台，可以通过这两个应用去管理Tomcat中所配置的虚拟主机、Tomcat中部署的web应用、Tomcat占用的JVM内存分配、JVM参数配比等

Host-manager主要用来管理 虚拟主机 信息。Tomcat启动之后,可以通过 http://localhost:8080/host-manager/html 访问该web应用。host-manager默认添加了访问权限控制,当打开网址时,需要输入用户名和密码(conf/tomcat-users.xml中配置) 。所以要想访问该页面,需要在conf/tomcat-users.xml中配置,并分配对应的角色:

1)admin-gui:用于控制页面访问权限

2)admin-script:用于控制以简单文本的形式进行访问

配置如下:

界面：

Manager用来管理部署在当前Tomcat上的web应用，访问路径为 http://localhost:8080/manager ，同样manager也添加了页面访问控制，因此我们需要为登录用户分配角色为：

Server Status查看服务器状态，给JVM内存优化参考数据

需要做的就是：按照你的需求配置Tomcat，只要你正确配置，Tomcat一般都能适合你的要求。下面是一系列关于Tomcat的配置技巧，这些技巧源自于我的书：《Tomcat权威指南》，希望对你有所帮助。 Jason Brittain

1． 配置系统管理（Admin Web Application）

大多数商业化的J2EE服务器都提供一个功能强大的管理界面，且大都采用易于理解的Web应用界面。Tomcat按照自己的方式，同样提供一个成熟的管理工具，并且丝毫不逊于那些商业化的竞争对手。Tomcat的Admin Web Application最初在4.1版本时出现，当时的功能包括管理context、data source、user和group等。当然也可以管理像初始化参数，user、group、role的多种数据库管理等。在后续的版本中，这些功能将得到很大的扩展，但现有的功能已经非常实用了。

Admin Web Application被定义在自动部署文件：CATALINA_BASE/webapps/admin.xml 。

（译者注：CATALINA_BASE即tomcat安装目录下的server目录）

你必须编辑这个文件，以确定Context中的 docBase参数是绝对路径。也就是说，CATALINA_BASE/webapps/admin.xml 的路径是绝对路径。作为另外一种选择，你也可以删除这个自动部署文件，而在server.xml文件中建立一个Admin Web Application的context，效果是一样的。你不能管理Admin Web Application这个应用，换而言之，除了删除CATALINA_BASE/webapps/admin.xml ，你可能什么都做不了。

如果你使用UserDatabaseRealm（默认），你将需要添加一个user以及一个role到CATALINA_BASE/conf /tomcat-users.xml 文件中。你编辑这个文件，添加一个名叫“admin”的role 到该文件中，如下：

＜role name="admin"/＞

你同样需要有一个用户，并且这个用户的角色是“admin”。象存在的用户那样，添加一个用户（改变密码使其更加安全）：

＜user name="admin" password="deep_dark_secret" roles="admin"/＞

当你完成这些步骤后，请重新启动Tomcat，访问http://localhost:8080/admin，你将看到一个登录界面。Admin Web Application采用基于容器管理的安全机制，并采用了Jakarta Struts框架。一旦你作为“admin”角色的用户登录管理界面，你将能够使用这个管理界面配置Tomcat。

2．配置应用管理（Manager Web Application）

Manager Web Application让你通过一个比Admin Web Application更为简单的用户界面，执行一些简单的Web应用任务。

Manager Web Application被被定义在一个自动部署文件中：

CATALINA_BASE/webapps/manager.xml 。

你必须编辑这个文件，以确保context的docBase参数是绝对路径，也就是说 CATALINA_HOME/server/webapps/manager的绝对路径。

（译者注：CATALINA_HOME即 tomcat安装目录）

如果你使用的是UserDatabaseRealm，那么你需要添加一个角色和一个用户到 CATALINA_BASE/conf/tomcat-users.xml文件中。接下来，编辑这个文件，添加一个名为“manager”的角色到该文件中：

＜role name=”manager”＞

你同样需要有一个角色为“manager”的用户。像已经存在的用户那样，添加一个新用户（改变密码使其更加安全）：

＜user name="manager" password="deep_dark_secret" roles="manager"/＞

然后重新启动Tomcat，访问http://localhost/manager/list，将看到一个很朴素的文本型管理界面，或者访问http://localhost/manager/html/list，将看到一个HMTL的管理界面。不管是哪种方式都说明你的Manager Web Application现在已经启动了。

Manager application让你可以在没有系统管理特权的基础上，安装新的Web应用，以用于测试。如果我们有一个新的web应用位于/home/user /hello下在，并且想把它安装到 /hello下，为了测试这个应用，我们可以这么做，在第一个文件框中输入“/hello”（作为访问时的path），在第二个文本框中输入“file: /home/user/hello”（作为Config URL）。

Manager application还允许你停止、重新启动、移除以及重新部署一个web应用。停止一个应用使其无法被访问，当有用户尝试访问这个被停止的应用时，将看到一个503的错误??“503 - This application is not currently available”。

移除一个web应用，只是指从Tomcat的运行拷贝中删除了该应用，如果你重新启动Tomcat，被删除的应用将再次出现（也就是说，移除并不是指从硬盘上删除）。

3．部署一个web应用

有两个办法可以在系统中部署web服务。

1＞ 拷贝你的WAR文件或者你的web应用文件夹（包括该web的所有内容）到$CATALINA_BASE/webapps目录下。

2＞ 为你的web服务建立一个只包括context内容的XML片断文件，并把该文件放到$CATALINA_BASE/webapps目录下。这个web应用本身可以存储在硬盘上的任何地方。

如果你有一个WAR文件，你若想部署它，则只需要把该文件简单的拷贝到 CATALINA_BASE/webapps目录下即可，文件必须以“.war”作为扩展名。一旦Tomcat监听到这个文件，它将（缺省的）解开该文件包作为一个子目录，并以WAR文件的文件名作为子目录的名字。接下来，Tomcat将在内存中建立一个context，就好象你在server.xml文件里建立一样。当然，其他必需的内容，将从server.xml中的DefaultContext获得。

部署web应用的另一种方式是写一个Context XML片断文件，然后把该文件拷贝到CATALINA_BASE/webapps目录下。一个Context片断并非一个完整的XML文件，而只是一个 context元素，以及对该应用的相应描述。这种片断文件就像是从server.xml中切取出来的context元素一样，所以这种片断被命名为 “context片断”。

举个例子，如果我们想部署一个名叫MyWebApp.war的应用，该应用使用realm作为访问控制方式，我们可以使用下面这个片断：

＜!--

Context fragment for deploying MyWebApp.war

--＞

＜Context path="/demo" docBase="webapps/MyWebApp.war"

debug="0" privileged="true"＞

＜Realm className="org.apache.catalina.realm.UserDatabaseRealm"

resourceName="UserDatabase"/＞

＜/Context＞

把该片断命名为“MyWebApp.xml”，然后拷贝到CATALINA_BASE/webapps目录下。

这种context片断提供了一种便利的方法来部署web应用，你不需要编辑server.xml，除非你想改变缺省的部署特性，安装一个新的web应用时不需要重启动Tomcat。

4．配置虚拟主机（Virtual Hosts）

关于server.xml中“Host”这个元素，只有在你设置虚拟主机的才需要修改。虚拟主机是一种在一个web服务器上服务多个域名的机制，对每个域名而言，都好象独享了整个主机。实际上，大多数的小型商务网站都是采用虚拟主机实现的，这主要是因为虚拟主机能直接连接到Internet并提供相应的带宽，以保障合理的访问响应速度，另外虚拟主机还能提供一个稳定的固定IP。

基于名字的虚拟主机可以被建立在任何web服务器上，建立的方法就是通过在域名服务器（DNS）上建立IP地址的别名，并且告诉web服务器把去往不同域名的请求分发到相应的网页目录。因为这篇文章主要是讲 Tomcat，我们不准备介绍在各种操作系统上设置DNS的方法，如果你在这方面需要帮助，请参考《DNS and Bind》一书，作者是Paul Albitz and Cricket Liu (O'Reilly)。为了示范方便，我将使用一个静态的主机文件，因为这是测试别名最简单的方法。

在Tomcat中使用虚拟主机，你需要设置DNS或主机数据。为了测试，为本地IP设置一个IP别名就足够了，接下来，你需要在server.xml中添加几行内容，如下：

＜Server port="8005" shutdown="SHUTDOWN" debug="0"＞

＜Service name="Tomcat-Standalone"＞

＜Connector className="org.apache.coyote.tomcat4.CoyoteConnector"

port="8080" minProcessors="5" maxProcessors="75"

enableLookups="true" redirectPort="8443"/＞

＜Connector className="org.apache.coyote.tomcat4.CoyoteConnector"

port="8443" minProcessors="5" maxProcessors="75"

acceptCount="10" debug="0" scheme="https" secure="true"/＞

＜Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"

clientAuth="false" protocol="TLS" /＞

＜/Connector＞

＜Engine name="Standalone" defaultHost="localhost" debug="0"＞

＜!-- This Host is the default Host --＞

＜Host name="localhost" debug="0" appBase="webapps"

unpackWARs="true" autoDeploy="true"＞

＜Context path="" docBase="ROOT" debug="0"/＞

＜Context path="/orders" docBase="/home/ian/orders" debug="0"

reloadable="true" crossContext="true"＞

＜/Context＞

＜/Host＞

＜!-- This Host is the first "Virtual Host": http://www.example.com/ --＞

＜Host name="www.example.com" appBase="/home/example/webapp"＞

＜Context path="" docBase="."/＞

＜/Host＞

＜/Engine＞

＜/Service＞

＜/Server＞

Tomcat的server.xml文件，在初始状态下，只包括一个虚拟主机，但是它容易被扩充到支持多个虚拟主机。在前面的例子中展示的是一个简单的server.xml版本，其中粗体部分就是用于添加一个虚拟主机。每一个Host元素必须包括一个或多个 context元素，所包含的context元素中必须有一个是默认的context，这个默认的context的显示路径应该为空（例如，path=””）。

5．配置基础验证（Basic Authentication）

容器管理验证方法控制着当用户访问受保护的web应用资源时，如何进行用户的身份鉴别。当一个web应用使用了Basic Authentication（BASIC参数在web.xml文件中auto-method元素中设置），而有用户访问受保护的web应用时，Tomcat将通过HTTP Basic Authentication方式，弹出一个对话框，要求用户输入用户名和密码。在这种验证方法中，所有密码将被以64位的编码方式在网络上传输。

注意：使用Basic Authentication通过被认为是不安全的，因为它没有强健的加密方法，除非在客户端和服务器端都使用HTTPS或者其他密码加密码方式（比如，在一个虚拟私人网络中）。若没有额外的加密方法，网络管理员将能够截获（或滥用）用户的密码。但是，如果你是刚开始使用Tomcat，或者你想在你的 web应用中测试一下基于容器的安全管理，Basic Authentication还是非常易于设置和使用的。只需要添加＜security-constraint＞和＜login-config＞两个元素到你的web应用的web.xml文件中，并且在CATALINA_BASE/conf/tomcat-users.xml 文件中添加适当的＜role＞和＜user＞即可，然后重新启动Tomcat。

下面例子中的web.xml摘自一个俱乐部会员网站系统，该系统中只有member目录被保护起来，并使用Basic Authentication进行身份验证。请注意，这种方式将有效的代替Apache web服务器中的.htaccess文件。

＜!--

Define the Members-only area, by defining

a "Security Constraint" on this Application, and

mapping it to the subdirectory (URL) that we want

to restrict.

--＞

＜security- constraint＞

＜web-resource-collection＞

＜web-resource-name＞

Entire Application

＜/web-resource-name＞

＜url-pattern＞/members/*＜/url- pattern＞

＜/web-resource-collection＞

＜auth-constraint＞

＜role- name＞member＜/role-name＞

＜/auth-constraint＞

＜/security- constraint＞

＜!-- Define the Login Configuration for this Application --＞

＜login-config＞

＜auth-method＞BASIC＜/auth-method＞

＜realm- name＞My Club Members-only Area＜/realm-name＞

＜/login-config＞

6．配置单点登录（Single Sign-On）

一旦你设置了realm和验证的方法，你就需要进行实际的用户登录处理。一般说来，对用户而言登录系统是一件很麻烦的事情，你必须尽量减少用户登录验证的次数。作为缺省的情况，当用户第一次请求受保护的资源时，每一个web应用都会要求用户登录。如果你运行了多个web应用，并且每个应用都需要进行单独的用户验证，那这看起来就有点像你在与你的用户搏斗。用户们不知道怎样才能把多个分离的应用整合成一个单独的系统，所有他们也就不知道他们需要访问多少个不同的应用，只是很迷惑，为什么总要不停的登录。

Tomcat 4的“single sign-on”特性允许用户在访问同一虚拟主机下所有web应用时，只需登录一次。为了使用这个功能，你只需要在Host上添加一个 SingleSignOn Valve元素即可，如下所示：

＜Valve className="org.apache.catalina.authenticator.SingleSignOn"

debug="0"/＞

在Tomcat初始安装后，server.xml的注释里面包括SingleSignOn Valve配置的例子，你只需要去掉注释，即可使用。那么，任何用户只要登录过一个应用，则对于同一虚拟主机下的所有应用同样有效。

使用single sign-on valve有一些重要的限制：

1＞ value必须被配置和嵌套在相同的Host元素里，并且所有需要进行单点验证的web应用（必须通过context元素定义）都位于该Host下。

2＞ 包括共享用户信息的realm必须被设置在同一级Host中或者嵌套之外。

3＞ 不能被context中的realm覆盖。

4＞ 使用单点登录的web应用最好使用一个Tomcat的内置的验证方式（被定义在web.xml中的＜auth-method＞中），这比自定义的验证方式强，Tomcat内置的的验证方式包括basic、digest、form和client-cert。

5＞ 如果你使用单点登录，还希望集成一个第三方的web应用到你的网站中来，并且这个新的web应用使用它自己的验证方式，而不使用容器管理安全，那你基本上就没招了。你的用户每次登录原来所有应用时需要登录一次，并且在请求新的第三方应用时还得再登录一次。当然，如果你拥有这个第三方web应用的源码，而你又是一个程序员，你可以修改它，但那恐怕也不容易做。

6＞ 单点登录需要使用cookies。

7．配置用户定制目录（Customized User Directores）

一些站点允许个别用户在服务器上发布网页。例如，一所大学的学院可能想给每一位学生一个公共区域，或者是一个ISP希望给一些web空间给他的客户，但这又不是虚拟主机。在这种情况下，一个典型的方法就是在用户名前面加一个特殊字符（~），作为每位用户的网站，比如：

http://www.cs.myuniversity.edu/~username

http://members.mybigisp.com/~username

Tomcat提供两种方法在主机上映射这些个人网站，主要使用一对特殊的Listener元素。Listener的 className属性应该是org.apache.catalina.startup.UserConfig，userClass属性应该是几个映射类之一。如果你的系统是Unix，它将有一个标准的/etc/passwd文件，该文件中的帐号能够被运行中的Tomcat很容易的读取，该文件指定了用户的主目录，使用PasswdUserDatabase 映射类。

＜Listener className="org.apache.catalina.startup.UserConfig"

directoryName="public_html"

userClass="org.apache.catalina.startup.PasswdUserDatabase"/＞

web文件需要放置在像/home/users/ian/public_html 或者 /users/jbrittain/public_html一样的目录下面。当然你也可以改变public_html 到其他任何子目录下。

实际上，这个用户目录根本不一定需要位于用户主目录下里面。如果你没有一个密码文件，但你又想把一个用户名映射到公共的像/home一样目录的子目录里面，则可以使用HomesUserDatabase类。

＜Listener className="org.apache.catalina.startup.UserConfig"

directoryName="public_html" homeBase="/home"

userClass="org.apache.catalina.startup.HomesUserDatabase"/＞

这样一来，web文件就可以位于像/home/ian/public_html 或者 /home/jasonb/public_html一样的目录下。这种形式对Windows而言更加有利，你可以使用一个像c:\home这样的目录。

这些Listener元素，如果出现，则必须在Host元素里面，而不能在context元素里面，因为它们都用应用于Host本身。

8．在Tomcat中使用CGI脚本

Tomcat主要是作为Servlet/JSP容器，但它也有许多传统web服务器的性能。支持通用网关接口（Common Gateway Interface，即CGI）就是其中之一，CGI提供一组方法在响应浏览器请求时运行一些扩展程序。CGI之所以被称为通用，是因为它能在大多数程序或脚本中被调用，包括：Perl，Python，awk，Unix shell scripting等，甚至包括Java。当然，你大概不会把一个Java应用程序当作CGI来运行，毕竟这样太过原始。一般而言，开发Servlet总要比CGI具有更好的效率，因为当用户点击一个链接或一个按钮时，你不需要从操作系统层开始进行处理。

Tomcat包括一个可选的 CGI Servlet，允许你运行遗留下来的CGI脚本。

为了使Tomcat能够运行CGI，你必须做如下几件事：

1. 把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目录下）改名为servlets-cgi.jar。处理CGI的servlet应该位于 Tomcat的CLASSPATH下。

2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中，把关于＜servlet-name＞ CGI的那段的注释去掉（默认情况下，该段位于第241行）。

3. 同样，在Tomcat的CATALINA_BASE/conf/web.xml文件中，把关于对CGI进行映射的那段的注释去掉（默认情况下，该段位于第 299行）。注意，这段内容指定了HTML链接到CGI脚本的访问方式。

4. 你可以把CGI脚本放置在WEB-INF/cgi 目录下（注意，WEB-INF是一个安全的地方，你可以把一些不想被用户看见或基于安全考虑不想暴露的文件放在此处），或者你也可以把CGI脚本放置在 context下的其他目录下，并为CGI Servlet调整cgiPathPrefix初始化参数。这就指定的CGI Servlet的实际位置，且不能与上一步指定的URL重名。

5. 重新启动Tomcat，你的CGI就可以运行了。

在Tomcat中，CGI程序缺省放置在WEB-INF/cgi目录下，正如前面所提示的那样，WEB-INF目录受保护的，通过客户端的浏览器无法窥探到其中内容，所以对于放置含有密码或其他敏感信息的CGI脚本而言，这是一个非常好的地方。为了兼容其他服务器，尽管你也可以把CGI脚本保存在传统的 /cgi-bin目录，但要知道，在这些目录中的文件有可能被网上好奇的冲浪者看到。另外，在Unix中，请确定运行Tomcat的用户有执行CGI脚本的权限。

9．改变Tomcat中的JSP编译器（JSP Compiler）

在Tomcat 4.1（或更高版本，大概），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪，但这正是Ant有意为之的一部分，有一个API文档指导开发者在没有启动一个新的JVM的情况下，使用Ant。这是使用Ant进行Java开发的一大优势。另外，这也意味着你现在能够在Ant中使用任何javac支持的编译方式，这里有一个关于Apache Ant使用手册的javac page列表。使用起来是容易的，因为你只需要在＜init-param＞ 元素中定义一个名字叫“compiler”，并且在value中有一个支持编译的编译器名字，示例如下：

＜servlet＞

＜servlet-name＞jsp＜/servlet- name＞

＜servlet-class＞

org.apache.jasper.servlet.JspServlet

＜/servlet- class＞

＜init-param＞

＜param-name＞logVerbosityLevel＜/param-name＞

＜param- value＞WARNING＜/param-value＞

＜/init-param＞

＜init-param＞

＜param- name＞compiler＜/param-name＞

＜param-value＞jikes＜/param-value＞

＜/init- param＞

＜load-on-startup＞3＜/load-on-startup＞

＜/servlet＞

当然，给出的编译器必须已经安装在你的系统中，并且CLASSPATH可能需要设置，那处决于你选择的是何种编译器。

10．限制特定主机访问（Restricting Access to Specific Hosts）

有时，你可能想限制对Tomcat web应用的访问，比如，你希望只有你指定的主机或IP地址可以访问你的应用。这样一来，就只有那些指定的的客户端可以访问服务的内容了。为了实现这种效果，Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。

通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。

例如你可以把Admin Web application设置成只允许本地访问，设置如下：

＜Context path="/path/to/secret_files" ...＞

＜Valve className="org.apache.catalina.valves.RemoteAddrValve"

allow="127.0.0.1" deny=""/＞

＜/Context＞

如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。

站点根目录为： c:\wwwroot

站点一目录为： c:\wwwroot\aaa , 域名为 www.aaa.com

站点二目录为： c:\wwwroot\bbb , 域名为 www.bbb.com

站点三目录为： c:\wwwroot\ccc , 域名为 www.ccc.com

Tomcat 配置文件为： tomcat路径/conf/server.xml

站点根目录为： c:\wwwroot

站点一目录为： c:\wwwroot\aaa , 域名为 www.aaa.com

站点二目录为： c:\wwwroot\bbb , 域名为 www.bbb.com

Tomcat 配置文件为： tomcat路径/conf/server.xml

注: 若需不同域名访问将 <Host name="localhost" appBase="c:\wwwroot" unpackWARs="true" autoDeploy="true"> name 字段改为对应域名即可,多个域名可在 Host 标签内添加一个或多个 <Alias>www.abc.com</Alias> 即可。其中 Connector port、defaultHost、Hostname、appBase、docBase、日志 prefix 为你实际的即可。

a. 可以将不同 service 组件的 Engine name 都指定成 Catalina。

b. 可以将不同 service 组件的 Host appBase 指定成默认的 webapps。

c. <Context docBase="/data/java/appstore-web" path="" reloadable="true" /> 这个用于配置根路径项目，也就是 /data/java/appstore-web 包访问时是通过 ip:port 来访问，而不是传统的 ip:port/app

假设：

第一个tomcat文件夹为tomcat8-1，路径为 /home/tomcat8-1/

第二个tomcat文件夹为tomcat8-2，路径为 /home/tomcat8-2/

分别修改 tomcat 文件夹 /conf 目录下 server.xml 的监听端口为不同端口。

分别启动 tomcat 文件夹 /bin 目录下的 startup.sh 启动tomcat，停止同上文。

即可运行多个tomcat。

注：根据官方文档 tomcat8.5 且 JAVA7 及其以上才支持 SNI。如果 tomcat 版本较低且需要绑定多个域名情况下，建议使用反向代理方式部署 HTTPS。

在 <Connector port="8080"> 配置字段下新增 443 端口监听设置即可。

注：若IIS反向代理tomcat绑定https时，选择上启用SSL卸载。以免tomcat未配置HTTPS访问的情况下请求得不到正常响应。

如:

修改配置文件 tomcat路径/conf/tomcat-users.xml ：

---