tomcat_server.xml配置说明
1.1 Server
Server代表整个Catalina servlet容器。在server.xml配置文件中必须是顶层元素且唯一，给它配置的属性代表整个容器的属性。
1.2 Service
Service是这样一个集合：它由一个或者多个Connector，以及一个共享的处理引擎(Engine)组成。Engine负责处理所有Connector所获得的客户请求。
1.3 Connector
一个连接器(Connector)将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得响应结果，并返回给客户端。其protocal属性制定了该端口侦听的协议类型。
Tomcat有两个典型的连接器，一个直接侦听来自客户端浏览器的http请求，一个侦听来自其它Web服务器的请求。
Coyote Http/1.1 Connector 在端口8080处侦听来自客户浏览器的http请求，Coyote JK2 Connector 在端口8009处侦听来自其它Web服务器(比如Apache)的servlet/jsp代理请求。当使用Coyote Http/1.1 Connector时，Tomcat作为独立的Web容器，同时扮演Web服务器和Servlet容器的双重角色。当使用Coyote JK2 Connector时，Tomcat只扮演Servlet容器的角色，Web服务器则由Apache或者其他服务器来提供，由于这些专有的Web服务器在处理静态资源的性能和效率上要比Tomcat提供的Web服务器要好，所以很多人将Tomcat和Apache配合使用。
1.4 Engine
处理引擎(Engine)代表一个Service所属的请求处理机，它接受所有连接器传递过来的客户端请求，将处理结果返回给连接器，由连接器将最终响应返回给客户端。Engine必须配置在Service组件下。处理引擎下可以配置多个虚拟主机（Virtual Host），每个虚拟主机都有一个域名。当处理引擎获得一个请求时，它把该请求匹配到某个虚拟主机上，把请求交给该虚拟主机来处理。处理引擎有一个默认虚拟主机，当请求无法匹配到任何一个虚拟主机上时，交给默认虚拟主机来处理。
1.5 Host
代表一个虚拟主机，节点代码如：
<Host name="localhost" appBase="webapps" unpackWARs="true" xmlValidation="false" xmlNamespaceAware="false">
</Host>
其name是虚拟主机的名字，appBase是虚拟主机指向的目录，Tomcat启动时，会自动加载appBase下的应用。unpackWARs表示是否自动解压缩appBase下已打成WAR包的应用，autoDeploy表示在服务器运行的时候，将一个应用放入appBase下，是否自动部署。
每个虚拟主机和某个网络域名（Domain Name）相匹配。每个虚拟主机下都可以部署(deploy)一个或者多个Web应用程序（Web Application），每个Web应用程序对应于一个Context，有一个Context path。当虚拟主机获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理。匹配的方法是“最长匹配”，一个path=""的Context将成为该虚拟主机的默认Context。所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配。
在许多情况下，系统管理员希望将多个网络域名绑定到同一个虚拟主机，这就需要使用“主机别名”技术来实现。
1.6 Context
一个Context对应于一个Web应用程序，一个Web应用程序由一个或者多个Servlet组成。Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WebApp /Web-INF/web.xml载入Servlet类。当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类。如果找到，则执行该类，获得请求的响应，并返回。
2 Tomcat Server处理一个http请求的过程
假设来自客户的请求为： http://localhost:8080/macy/index.jsp
1) 请求发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得。
2) Connector把该请求交给它所在Service的Engine来处理，并等待来自Engine的响应。
3) Engine获得请求localhost/macy/index.jsp，匹配它所拥有的所有虚拟主机Host。
4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认虚拟主机）。
5) localhost Host获得请求/macy/index.jsp，匹配它所拥有的所有Context。
6) Host匹配到路径为/macy的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）。
7) path="/macy"的Context获得请求/index.jsp，在它的映射表中寻找对应的servlet。
8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类。
9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法。
10)Context把执行完了之后的HttpServletResponse对象返回给Host。
11)Host把HttpServletResponse对象返回给Engine。
12)Engine把HttpServletResponse对象返回给Connector。
13)Connector把HttpServletResponse对象返回给客户端浏览器。
介绍一种把应用从配置文件Server.xml独立出来的方法
Server.xml中可以配置部署应用需要的所有信息，从Tomcat5开始，应用配置可以从Server.xml独立出来，这也是Tomcat现在所推荐的配置方式，带来的一个好处，显而易见，更容易维护了。另一个好处，是在Servler.xml的修改，只能通过重启Tomcat 才能发生作用，分拆后，修改完成，可以不用重启Tomcat就发生作用。
应用的独立配置文件应该配置在路径$TOMCAT\conf\engineName\hostName\下，其中engineName是应用所在的 Engine的名字，对于本例而言是Catalina，hostName是应用所在的虚拟主机的名字，本例为localhost。配置文件的名字是这样约定的：如果访问路径就在虚拟主机下，那么名字为ROOT，如：ROOT.xml，其他情况下，文件名就是访问路径，不过需要用#替换路径中的/。本例中访问路径为/struts，相应的文件名是struts.xml，内容如下：
<Context docBase="C:/WAP/struts" reloadable="true"/>
其中docBase指定应用所在的目录，如果是相对目录，对应的就是虚拟主机下appBase的目录，也可以是绝对目录，这个时候应用在什么地方都可以。 reloadable表示是否支持热部署，比如class更新，如果reloadable为true，应用会重新部署。注意：在分拆后， Context的path属性将不再起作用，这是Tomcat6和之前的版本不同的地方。
以上配置完成，我们就可以访问应用了，访问地址是http://localhost:8080/struts
下面介绍资源的配置
这里指的主要是数据源的配置。Tomcat6使用的是DBCP数据源，它的配置方式如下：
<Resource name="jdbc/test" auth="Application" type="javax.sql.DataSource" maxActive="100"
maxIdle="30" maxWait="10000" username="sa" password="123456" driverClassName="com.microsoft.jdbc.sqlserver.SQLServerDriver"
url="jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=test"/>
它可以直接配置在Context元素下，这时数据源就只有他所属的应用能够访问。如果需要所有的应用能够访问，可以配置在$TOMCAT\conf\context.xml中，直接配置下根元素下即可。这个文件在启动tomcat的时候，所有的应用都会加载。
如果需要节省资源，共享同一个数据源，可以配置在Server.xml的GlobalNamingResources节点下，在应用中可以通过别名访问，提供别名的方式是在应用所在的元素下添加如下的子元素，例：
<ResouceLink name="jdbc/test2" global="jdbc/test" type="javax.sql.DataSource"/>
name就是别名，global是在GlobalNamingResources所定义的资源
1.1 Server
Server代表整个Catalina servlet容器。在server.xml配置文件中必须是顶层元素且唯一，给它配置的属性代表整个容器的属性。
1.2 Service
Service是这样一个集合：它由一个或者多个Connector，以及一个共享的处理引擎(Engine)组成。Engine负责处理所有Connector所获得的客户请求。
1.3 Connector
一个连接器(Connector)将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得响应结果，并返回给客户端。其protocal属性制定了该端口侦听的协议类型。
Tomcat有两个典型的连接器，一个直接侦听来自客户端浏览器的http请求，一个侦听来自其它Web服务器的请求。
Coyote Http/1.1 Connector 在端口8080处侦听来自客户浏览器的http请求，Coyote JK2 Connector 在端口8009处侦听来自其它Web服务器(比如Apache)的servlet/jsp代理请求。当使用Coyote Http/1.1 Connector时，Tomcat作为独立的Web容器，同时扮演Web服务器和Servlet容器的双重角色。当使用Coyote JK2 Connector时，Tomcat只扮演Servlet容器的角色，Web服务器则由Apache或者其他服务器来提供，由于这些专有的Web服务器在处理静态资源的性能和效率上要比Tomcat提供的Web服务器要好，所以很多人将Tomcat和Apache配合使用。
1.4 Engine
处理引擎(Engine)代表一个Service所属的请求处理机，它接受所有连接器传递过来的客户端请求，将处理结果返回给连接器，由连接器将最终响应返回给客户端。Engine必须配置在Service组件下。处理引擎下可以配置多个虚拟主机（Virtual Host），每个虚拟主机都有一个域名。当处理引擎获得一个请求时，它把该请求匹配到某个虚拟主机上，把请求交给该虚拟主机来处理。处理引擎有一个默认虚拟主机，当请求无法匹配到任何一个虚拟主机上时，交给默认虚拟主机来处理。
1.5 Host
代表一个虚拟主机，节点代码如：
<Host name="localhost" appBase="webapps" unpackWARs="true" xmlValidation="false" xmlNamespaceAware="false">
</Host>
其name是虚拟主机的名字，appBase是虚拟主机指向的目录，Tomcat启动时，会自动加载appBase下的应用。unpackWARs表示是否自动解压缩appBase下已打成WAR包的应用，autoDeploy表示在服务器运行的时候，将一个应用放入appBase下，是否自动部署。
每个虚拟主机和某个网络域名（Domain Name）相匹配。每个虚拟主机下都可以部署(deploy)一个或者多个Web应用程序（Web Application），每个Web应用程序对应于一个Context，有一个Context path。当虚拟主机获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理。匹配的方法是“最长匹配”，一个path=""的Context将成为该虚拟主机的默认Context。所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配。
在许多情况下，系统管理员希望将多个网络域名绑定到同一个虚拟主机，这就需要使用“主机别名”技术来实现。
1.6 Context
一个Context对应于一个Web应用程序，一个Web应用程序由一个或者多个Servlet组成。Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WebApp /Web-INF/web.xml载入Servlet类。当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类。如果找到，则执行该类，获得请求的响应，并返回。
2 Tomcat Server处理一个http请求的过程
假设来自客户的请求为： http://localhost:8080/macy/index.jsp
1) 请求发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得。
2) Connector把该请求交给它所在Service的Engine来处理，并等待来自Engine的响应。
3) Engine获得请求localhost/macy/index.jsp，匹配它所拥有的所有虚拟主机Host。
4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认虚拟主机）。
5) localhost Host获得请求/macy/index.jsp，匹配它所拥有的所有Context。
6) Host匹配到路径为/macy的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）。
7) path="/macy"的Context获得请求/index.jsp，在它的映射表中寻找对应的servlet。
8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类。
9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法。
10)Context把执行完了之后的HttpServletResponse对象返回给Host。
11)Host把HttpServletResponse对象返回给Engine。
12)Engine把HttpServletResponse对象返回给Connector。
13)Connector把HttpServletResponse对象返回给客户端浏览器。
介绍一种把应用从配置文件Server.xml独立出来的方法
Server.xml中可以配置部署应用需要的所有信息，从Tomcat5开始，应用配置可以从Server.xml独立出来，这也是Tomcat现在所推荐的配置方式，带来的一个好处，显而易见，更容易维护了。另一个好处，是在Servler.xml的修改，只能通过重启Tomcat 才能发生作用，分拆后，修改完成，可以不用重启Tomcat就发生作用。
应用的独立配置文件应该配置在路径$TOMCAT\conf\engineName\hostName\下，其中engineName是应用所在的 Engine的名字，对于本例而言是Catalina，hostName是应用所在的虚拟主机的名字，本例为localhost。配置文件的名字是这样约定的：如果访问路径就在虚拟主机下，那么名字为ROOT，如：ROOT.xml，其他情况下，文件名就是访问路径，不过需要用#替换路径中的/。本例中访问路径为/struts，相应的文件名是struts.xml，内容如下：
<Context docBase="C:/WAP/struts" reloadable="true"/>
其中docBase指定应用所在的目录，如果是相对目录，对应的就是虚拟主机下appBase的目录，也可以是绝对目录，这个时候应用在什么地方都可以。 reloadable表示是否支持热部署，比如class更新，如果reloadable为true，应用会重新部署。注意：在分拆后， Context的path属性将不再起作用，这是Tomcat6和之前的版本不同的地方。
以上配置完成，我们就可以访问应用了，访问地址是http://localhost:8080/struts
下面介绍资源的配置
这里指的主要是数据源的配置。Tomcat6使用的是DBCP数据源，它的配置方式如下：
<Resource name="jdbc/test" auth="Application" type="javax.sql.DataSource" maxActive="100"
maxIdle="30" maxWait="10000" username="sa" password="123456" driverClassName="com.microsoft.jdbc.sqlserver.SQLServerDriver"
url="jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=test"/>
它可以直接配置在Context元素下，这时数据源就只有他所属的应用能够访问。如果需要所有的应用能够访问，可以配置在$TOMCAT\conf\context.xml中，直接配置下根元素下即可。这个文件在启动tomcat的时候，所有的应用都会加载。
如果需要节省资源，共享同一个数据源，可以配置在Server.xml的GlobalNamingResources节点下，在应用中可以通过别名访问，提供别名的方式是在应用所在的元素下添加如下的子元素，例：
<ResouceLink name="jdbc/test2" global="jdbc/test" type="javax.sql.DataSource"/>
name就是别名，global是在GlobalNamingResources所定义的资源
1096
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
