Tomcat6结构分析
tomcat在实际开发中大量使用，对其结构不了解的话在配置使用过程中容易出现各种奇怪的问题。
Server.xml在tomcat处于核心地位。当Tomcat启动时，Apache Commons Digester就会读取这份配置文件。
XML结构的本质是嵌套式的机构，Tomcat自身也按这种结构设计。
从这份示例server.xml文档也可以看出，Tomcat的结构和XML的结构是多么的一致。因此，要想弄清楚Tomcat的结构，最快捷的方法就是阅读配置文件。
tomcat结构如图：
对应的server.xml
1
<Server port="8008" shutdown="SHUTDOWN">
2 <Service name="Catalina">
3 <Connector port="8080" protocol="HTTP/1.1"
4 connectionTimeout="20000"
5 redirectPort="8443" URIEncoding="utf-8" />
6 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
7 <Engine name="Catalina" defaultHost="localhost">
8 <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
9 resourceName="UserDatabase"/>
10 <Host name="localhost" appBase="webapps"
11 unpackWARs="true" autoDeploy="true"
12 xmlValidation="false" xmlNamespaceAware="false">
13 <Context path="/test" reloadable="true" docBase="" />
14 </Host>
15 </Engine>
16 </Service>
17</Server> l
各部分说明：
1.Server
Server就是Tomcat自身，一个Tomcat程序实例（instance）。
代表整个容器,是Tomcat实例的顶层元素.由org.apache.catalina.Server接口来定义。
提供完整的JVM的独立组件，它可以包含一个或多个“Service”实例。服务器在指定的端口上监听shutdown命令。
它的一个重要属性就是关闭Tomcat的端口号。
测试命令：
telnet localhost 8008
输入：SHUTDOWN
结果：关闭tomcat
属性说明：
<Server port="8008" shutdown="SHUTDOWN">
1)className指定实现org.apache.catalina.Server接口的类.默认值为org.apache.catalina.core.StandardServer
2)port指定Tomcat监听shutdown命令端口.终止服务器运行时,必须在Tomcat服务器所在的机器上发出shutdown命令.该属性是必须的.
3)shutdown指定终止Tomcat服务器运行时,发给Tomcat服务器的shutdown监听端口的字符串.该属性必须设置
2.Service
Service由Connector和Engine组成，Engine可以对应一个或多个Connector。
Connector 主要负责对外交流，Engine主要处理Connector接受的请求，主要是处理内部事务。
是 Service 将它们连接在一起，共同负责处理所有Connector所获得的客户请求。
3.Connector
Connector代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果.
每个connector都有一个端口号，常用的Connector有两种，一种是HTTP Connector用来接收http请求，另一种是AJP Connect
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" URIEncoding="utf-8" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
port : 在端口号8080处侦听来自客户browser的HTTP1.1请求.如果把8080改成80,则只要输入 http://localhost/ 即可
protocol:设定Http协议,默认值为HTTP/1.1
4.Engine
Service中的请求处理机，接受和处理来自Connector 的请求。
5.Host
它由Host接口定义.一个Engine元素可以包含多个<Host>元素.每个<Host>的元素定义了一个虚拟主机.它包含了一个或多个Web应用.
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
appBase : 指定虚拟主机的目录,可以指定绝对目录,也可以指定相对于<CATALINA_HOME>的相对目录.如果没有此项,默认为<CATALINA_HOME>/webapps.
它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
autoDeploy:如果此项设为true,表示Tomcat服务处于运行状态时,能够监测appBase下的文件,如果有新有web应用加入进来,会自运发布这个WEB应用
unpackWARs:如果此项设置为true,表示把WEB应用的WAR文件先展开为开放目录结构后再运行.如果设为false将直接运行为WAR文件
alias:指定主机别名,可以指定多个别名
deployOnStartup:如果此项设为true,表示Tomcat服务器启动时会自动发布appBase目录下所有的Web应用.
如果Web应用中的server.xml没有相应的<Context>元素,将采用Tomcat默认的Context
6.Context
它由Context接口定义.是使用最频繁的元素.每个<Context元素代表了运行在虚拟主机上的单个Web应用.一个<Host>可以包含多个<Context>元素.
Context 代表 Servlet 的 Context，它具备了 Servlet 运行的基本环境，理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。
Context 最重要的功能就是管理它里面的 Servlet 实例，Servlet 实例在 Context 中是以 Wrapper 出现的，还有一点就是 Context 如何才能找到正确的 Servlet 来执行它呢？ Tomcat5 以前是通过一个 Mapper 类来管理的，Tomcat5 以后这个功能被移到了 request 中。
<Context path="/test" reloadable="true" docBase="" />
path : 该Context的路径名是""，故该Context是该Host的默认Context
docBase : 该Context的根目录是webapps/mycontext/
reloadable:如果这个属性设为true, Tomcat服务器在运行状态下会监视在WEB-INF/classes和Web-INF/lib目录CLASS文件的改运.如果监视到有class文件被更新,服务器自重新加载Web应用
useNaming:指定是否支持JNDI,默认值为了true
cookies指定是否通过Cookies来支持Session,默认值为true
<Context path="" docBase="mycontext" debug="0"/>
生命周期（Lifecycle）
Tomcat使用的一种“插件式（plugable）”的结构，管理这些插件的生命周期。当用户启动tomcat时，tomcat中的插件也会一起启动，当关闭时也是同样。通过Lifecycle接口：LifecycleEvent和LifecycleListener 实现的。
几乎所有的Tomcat组件都实现了Lifecycle接口，主要的控制组件都有LifecycleSuport对象，它们使用这个对象来管理其中的所有子Lifecycle对象。使用LifecycleSupport对象，当顶层对象调用start()方法时，它就会调用它的子组件的start()方法，子组件的子组件又会调用start()方法。
LifecycleListener接口可以被添加到任何层次的Tomcat容器 (Server, Service, Engine, Host, or Context)，在Server这个级别，默认的Listener有三个。用户可以定义自己的Listener，不过需要将其在server.xml或context.xml中添加配置。用户自定义的Listener需要继承LifecycleListene接口。