我们知道了tomcat的整体框架了， 也明白了里面都有些什么组件， 以及各个组件是干什么用的了。

http://www.csdn.net/Develop/read_article.asp?id=27225

我想，接下来我们应该去了解一下 tomcat 是如何处理jsp和servlet请求的。

1.  我们以一个具体的例子，来跟踪TOMCAT，看看它是如何把Request一层一层地递交给下一个容器，并最后交给Wrapper来处理的。

以http://localhost:8080/web/login.jsp为例子

（以下例子，都是以tomcat4 源码为参考）

这篇心得主要分为3个部分： 前期， 中期， 和末期。

 前期：讲解了在浏览器里面输入一个URL，是怎么被tomcat抓住的。

中期：讲解了被tomcat抓住后，又是怎么在各个容器里面穿梭， 最后到达最后的处理地点。

末期：讲解到达最后的处理地点后，又是怎么具体处理的。

2、 前期 Request的born.

    在这里我先简单讲一下request这个东西。

     我们先看着这个URL：http://localhost:8080/web/login.jsp 它是动用了8080端口来进行socket通讯的。

     我们知道, 通过

       InputStream in = socket.getInputStream() 和

       OutputStream out = socket.getOutputStream()

     就可以实现消息的来来往往了。

     但是如果把Stream给应用层看，显然操作起来不方便。

     所以，在tomcat 的Connector里面， socket被封装成了Request和Response这两个对象。

     我们可以简单地把Request看成管发到服务器来的数据，把Response看成想发出服务器的数据。

     但是这样又有其他问题了啊？ Request这个对象是把socket封装起来了， 但是他提供的又东西太多了。

     诸如Request.getAuthorization(), Request.getSocket()。 像Authorization 这种东西开发人员拿来基本上用不太着，而像socket这种东西，暴露给开发人员又有潜在的危险。 而且啊， 在Servlet Specification里面标准的通信类是ServletRequest和HttpServletRequest，而非这个Request类。 So, So, So. Tomcat必须得捣持捣持Request才行。 最后tomcat选择了使用捣持模式（应该叫适配器模式）来解决这个问题。它把org.apache.catalina.Request 捣持成了 org.apache.coyote.tomcat4.CoyoteRequest。 而CoyoteRequest又实现了ServletRequest和HttpServletRequest 这两种接口。 这样就提供给开发人员需要且刚刚需要的方法了。

    ok, 让我们在 tomcat的顶层容器 - StandardEngin 的invoke()方法这里设置一个断点， 然后访问

    http://localhost:8080/web/login.jsp， 我们来看看在前期都会路过哪些地方：

       1. run(): 536, java.lang.Thread, Thread.java

       CurrentThread

      2. run():666, org.apache.tomcat.util.threads.ThreadPool$ControlRunnable, ThreadPool.java

               ThreadPool

       3. runIt():589, org.apache.tomcat.util.net.TcpWorkerThread, PoolTcpEndpoint.java

         ThreadWorker

4.        processConnection():  549

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler, Http11Protocol.java

                  http protocol parser

      5. Process(): 781, org.apache.coyote.http11.Http11Processor, Http11Processor.java

          http request processor

       6. service(): 193, org.apache.coyote.tomcat4.CoyoteAdapter,CoyoteAdapter.java

         adapter

       7. invoke(): 995, org.apache.catalina.core.ContainerBase, ContainerBase.java

   StandardEngin

    1. 主线程

    2. 启动线程池.

    3. 调出线程池里面空闲的工作线程。

    4. 把8080端口传过来由httpd协议封装的数据，解析成Request和Response对象。

    5. 使用Http11Processor来处理request

    6. 在Http11Processor里面， 又会call CoyoteAdapter来进行适配处理，把Request适配成实现了ServletRequest和HttpServletRequest接口的CoyoteRequest.

7. 到了这里，前期的去毛拔皮工作就基本上搞定，可以交给StandardEngin 做核心的处理工作了。

3. 中期。 在各个容器间的穿梭。

    Request在各个容器里面的穿梭大致是这样一种方式：

    每个容器里面都有一个管道（pipline）， 专门用来传送Request用的。

    管道里面又有好几个阀门（valve）， 专门用来过滤Request用的。

    在管道的低部通常都会放上一个默认的阀们。 这个阀们至少会做一件事情，就是把Request交给子容器。

    让我们来想象一下：

     当一个Request进入一个容器后， 它就在管道里面流动，波罗~ 波罗~ 波罗~ 地穿过各个阀门。在流到最后一个阀门的时候，吧唧~ 那个该死的阀门就把它扔给了子容器。 然后又开始 波罗~ 波罗~ 波罗~ ... 吧唧~.... 波罗~ 波罗~ 波罗~ ....吧唧~....

    就是通过这种方式， Request 走完了所有的容器。（ 感觉有点像消化系统，最后一个地方有点像那里~ ）

3.1 StandardEngin 的pipeline里面放的是：StandardEnginValve

在这里，VALVE做了三件事：

1.   验证传递过来的request是不是httpservletRequest.

2    验证传递过来的 request 是否携带了host header信息.

3    选择相应的host去处理它。（一般我们都只有一个host:localhost，也就是127.0.0.1）。

到了这个地方，我们的request就已经完成了在Engin这个部分的历史使命，通向前途未卜的下一站： host了。

3.2 StandardHost 的pipline里面放的是： StandardHostValve

1.   验证传递过来的request是不是httpservletRequest.

2.   根据Request来确定哪个Context来处理。

Context其实就是webapp，比如http://localhost:8080/web/login.jsp

这里web就是Context罗！

3.   既然确定了是哪个Context了，那么就应该把那个Context的classloader付给当前线程了。

        Thread.currentThread().setContextClassLoader(context.getLoader().getClassLoader());

   这样request就只看得见指定的context下面的classes啊， jar啊这些，而看不见tomcat本身的类，什么Engin啊， Valve啊。不然还得了啊！

4. 既然request到了这里了，看来用户是准备访问web这个web app了，咋们得更新一下这个用户的session不是！ Ok , 就由manager更新一下用户的session信息

5. 交给具体的Context 容器去继续处理Request.

6. Context处理完毕了，把classloader还回来。

3.3 StandardContext 的pipline里面放的是： StandardContextValve

1.   验证传递过来的request是不是httpservletRequest.

2.   如果request意图不轨，想要访问/meta-inf, /web-inf这些目录下的东西，呵呵，没有用D!

3.   这个时候就会根据Request到底是Servlet，还是jsp，还是静态资源来决定到底用哪种Wrapper来处理这个Reqeust了。

4.   一旦决定了到底用哪种Wrapper，OK，交给那个Wrapper处理。

4. 末期。 不同的需求是怎么处理的.

StandardWrapper

之前对Wrapper没有做过讲解，其实它是这样一种东西。

我们在处理Request的时候，可以分成3种。

处理静态的： org.apache.catalina.servlets.DefaultServlet  

处理jsp的：org.apache.jasper.servlet.JspServlet

处理servlet的：org.apache.catalina.servlets.InvokerServlet

不同的request就用这3种不同的servlet去处理。

Wrapper就是对它们的一种简单的封装，有了Wrapper后，我们就可以轻松地拦截每次的Request。也可以容易地调用servlet的init()和destroy()方法， 便于管理嘛！

具体情况是这么滴：

   如果request是找jsp文件，StandardWrapper里面就会封装一个org.apache.jasper.servlet.JspServlet去处理它。

   如果request是找 静态资源 ，StandardWrapper里面就会封装一个org.apache.jasper.servlet.DefaultServlet 去处理它。

   如果request是找servlet ，StandardWrapper里面就会封装一个org.apache.jasper.servlet.InvokerServlet 去处理它。

StandardWrapper同样也是容器，既然是容器， 那么里面一定留了一个管道给request去穿，管道低部肯定也有一个阀门(注1)，用来做最后一道拦截工作.

在这最底部的阀门里，其实就主要做了两件事:

   一是启动过滤器，让request在N个过滤器里面筛一通，如果OK！ 那就PASS。 否则就跳到其他地方去了。

   二是servlet.service((HttpServletRequest) request,(HttpServletResponse) response); 这个方法.

     如果是 JspServlet， 那么先把jsp文件编译成servlet_xxx, 再invoke servlet_xxx的servie()方法。

     如果是 DefaultServlet， 就直接找到静态资源，取出内容， 发送出去。

     如果是 InvokerServlet， 就调用那个具体的servlet的service()方法。

   ok! 完毕。

注1: StandardWrapper 里面的阀门是最后一道关口了。 如果这个阀门欲意把request交给StandardWrapper 的子容器处理。 对不起， 在设计考虑的时候， Wrapper就被考虑成最末的一个容器， 压根儿就不会给Wrapper添加子容器的机会！ 如果硬是要调用addChild(), 立马抛出IllegalArgumentException！

参考：

     <http://jakarta.apache.org/tomcat/>
   <http://www.onjava.com/pub/a/onjava/2003/05/14/java_webserver.html>

从Tomcat中得到更多－Tomcat的源码分析

赵晨希

<zhaochenxi@vip.sina.com>

本文的作者通过对TomCat源代码的研究，向读者描述了在tomcat3.3和TomCat4.0中在设计方面使用的不同设计理念和模式，希望对广大开发者在设计自己的系统时有所帮助。

关于Tomcat的基本情况

众所周知Tomcat是一个免费的开放源码的Serlvet容器，它是Apache基金会的Jakarta项目中的一个核心项目，也是sun公司官方推荐的servlet和jsp容器，同时它还获得过多种荣誉。servlet和jsp的最新规范都可以在tomcat的新版本中得到实现。Tomcat具有轻量级和灵活嵌入到应用系统中的优点，所以得到了广泛的应用。在Tomcat的发展中，Sun在1999年六月宣布参与Jakarta项目的Tomcat servlet容器和Jsp引擎的开发，使得Tomcat在3.x和4.x版之间系统设计上发生了比较大的变化。Tomcat的其他信息我就不多说了。有兴趣的朋友可以访问http://jakarta.apache.org/ 的官方网站得到更多的信息。

因为工作的原因，我改写了Tomcat的一些代码，所以我粗略的研究了一下Tomcat3.3和Tomcat4.0的源码，深深地被这个开放软件的设计和实现吸引，感觉到这个软件中有许多值得我们学习和借鉴的地方。我把自己的理解介绍给大家算是抛砖引玉，不足和偏差还望大家批评指正。下面就来让我们看看从 Tomcat那里我们可以得到什么。

从Tomcat中学习设计模式

Tomcat的设计和实现处处体现着设计模式的思想，它的基本流程是首先通过解析xml格式的配置文件，获得系统的配置和应用信息，然后加载定制的组件模块提供各种系统服务。系统的各部分功能都是通过可以配置的组件模块来实现的。Tomcat实现中像Observer，Facade，Adapter， Singleton等多种设计模型在Tomcat的源码中随处可见，为我们提供了一个很好的学习设计模式的平台。我主要介绍一下Tomcat中程序流程控制所采用的设计模式，这是一个程序运行的框架。前面提到由于Sun公司的参与，Tomcat虽然基本的流程没有变化，但是Tomcat3.3和 Tomcat4.0版本之间在概念上还是有很大地不同的。Tomcat3.3整体上是模块化的设计，而Tomcat4.0可以看作是采用面向组件技术进行设计的。组件是比模块更高级的一个层次。我们可以通过比较它们之间的不同来了解实现一个服务器软件可以采用的设计模式和实现方式。

Tomcat3.3的基本结构设计

Tomcat3.3采用的是一种模块化的链状的控制结构，它的主要设计模式有：

Chain of responsibility（责任链）

作为一个基于请求响应模式的服务器，在Tomcat3.3中采用一种链状处理的控制模式。请求在链上的各个环节上传递，在任一环节上可以存在若干个"监听器"处理它。这样做的目的是避免请求的发送者和接受者之间的直接耦合，从而可以为其他的对象提供了参与处理请求的机会。采用这个方式不但可以通过"监听器 "实现系统功能，而且可以通过添加新的"监听器"对象实现系统功能的扩展。

Interceptor（监听器）

"监听器"是一个过去使用的名称，它可以看作 "模块(module)"的同义词。它是Tomcat功能模块构建和扩展的方式。Tomcat3.3的大部分功能都是通过"监听器"实现的。在 Tomcat中提供了一种简单的钩子（Hook）机制，监听器对钩子中感兴趣的事件进行注册，事件发生后通过钩子唤醒已注册的"监听器"对象，"监听器" 对象对Tomcat内核事件进行处理。这些模块都是围绕着"责任链"和"策略"的模式进行设计。通过"监听器"你可以监听各种特殊事件，进而控制处理请求的各个步骤---解析，认证，授权，会话，响应提交，缓冲区提交等等。

Strategy（策略）

所谓策略是指"定义一组规则，按照规则进行对象封装，使得他们只在规则内部进行交互"。通过策略模式使得Tomcat作为一个开源项目在开放环境下的开发和演变变得更轻松。通过这种模式把复杂的算法分成模块然后不同的开发组提供各自的实现。从而实现调用模块的代码和模块的具体实现代码的分别开发。这样可以使我们专注于问题的重点，并且减少问题之间的依赖性。在Tomcat中大量采用了策略的设计模式，通过这种方式每一种服务都提供了多种的实现（例如Tomcat中有2－3种认证模块），在代码完成后可以从稳定性和性能表现的考虑选择更好的实现。策略模式对开放式环境下的软件开发非常有用。

我们通过简化的类图(见图一)和时序图(见图二)，描述一下Tomcat3.3的程序流程控制如何通过监听器和责任链实现。

图?1.?简化的类图

关于类图的简单说明：

BaseInterceptor：

是所有监听器的基类，描述了基本的模块功能和对各种事件的缺省处理。

ContextManage：

系统的核心控制对象，进行请求处理和系统配置。它维护了全局的属性、web应用的内容和全局模块等多种信息，责任链的钩子实现也在其中。

PoolTcpConnector：

一个处理TCP连接的连接器对象，从BaseIntercepor派生。它包括一个具体处理socket连接的PoolTcpEndPoint类对象。

PoolTcpEndPoint：

处理实际的tcp连接。它有一个连接池对象ThreadPool和运行在独立线程中的应用逻辑类TcpWorkThread。

TcpWorkThead：

处理socket连接事务，调用接口TcpConnectionHandler中的请求处理方法。

Http10Interceptor：

从PoolTcpConnector派生，实现了TcpConnectionHandler接口，是一个真正的监听器对象。它按照Http1.0的协议标准对tcp连接进行处理，调用核心对象ContextManage的服务方法。

图?2.?简化的时序图

关于时序图中需要说明的地方：

1. 在contextManager初始化后会根据配置信息，加载基本的应用模块和各种监听器对象，创建钩子（Hook）机制，注册监听器对象，形成一个责任链。然后对各个监听器对象发出engineInit，engineStart消息。
2. 一个请求在经过http10interceptor基本处理后提交到contextManager处理。
3. ContextManager的processRequest方法进行请求的处理。按照处理的步骤会顺序地发出H_postReadRequest， H_contextMap， H_requestMap等消息。然后从hook中取得对该消息注册的监听器对象，调用他们的处理方法，从而实现责任链方式。以下的代码片断说明了这种方式：

4.           BaseInterceptor ri[];

5.           //取得注册对象

6.           ri=defaultContainer.getInterceptors(Container.H_postReadRequest);

7.           //执行注册对象的对消息的处理方法

for( int i=0; i< ri.length; i++ ) { status=ri[i].postReadRequest( req );      ......}

8. 系统退出时contextManager发出engineStop消息。

Tomcat3.3的基本程序结构就是采用上面介绍的方式设计的。它给我们的设计和开发提供了一个很好的思路，通过这种模式可以轻松的实现一个事件驱动的基于模块化设计的应用程序。各个功能通过模块实现，通过对责任链上的消息和处理步骤的改动或者添加新的监听器对象可以非常方便的扩展Tomcat的功能。所以这是一个非常好的设计。

Tomcat4.0的基本结构设计

虽然Tomcat3.x已经实现了一个非常好的设计体系，但是在Sun公司加入后， Tomcat4.0中还是引入了不同的实现方式。主要的区别是Tomcat4.0采用了面向组件的设计方式， Tomcat4.0中的功能是由组件提供的，控制流程通过组件之间的通讯完成。这不同于Tomcat3.3中的基于模块的链式控制结构。

面 向组件的技术(CO)是比面向对象的技术(OOP)更高一层的抽象，它融合了面向对象的优点，加入了安全性和可扩展的模块设计，可以更好的映射问题域空 间。采用面向组件的设计会带来很多好处，可以提高复用性、降低耦合度和通过组装构成系统等等。面向组件编程中有许多概念与原来面向对象的编程是不同的，例 如：

Message(消息)：定义抽象操作； Method(方法)：定义具体的操作； Interface(接口)：一组消息的集合； Implementation(实现)：一组方法的集合； Module(模块)：静态的数据结构, Type(类型)：动态的数据结构。

软件组件不同与功能模块，它具有以下特性：

• 组件是一个自包容的模块，具有定义清楚的界线，对外提供它的能力、属性和事件。
• 组件自身不保留状态。
• 组件可以是一个类，大部分情况下是一组类。

在Java 语言中对面向组件编程的支持是通过JavaBeans模型获得的。JavaBean组件框架提供了对事件和属性的支持。Tomcat4.0的组件的就是通过JavaBean技术实现的。这是它和Tomcat3.3中最大的不同。下面我们来看一下Tomcat4.0是如何通过面向组件编程来实现程序流程控制的。

面向组件编程时设计组件是关键，从Tomcat4.0中可以看出主要使用了以下的设计模式：

Separation of Concerns（SOC）

设计组件时应该从不同的问题领域，站在不同的观点上分析，把每一种属性分别考虑。举一个例子FileLogger组件，它用于把系统日志信息保存到文件系统中。按照这种模式分析，我们从不同的角度看待它：它如何启动服务、停止服务和进行通讯？它的具体的功能有哪些？别的组件可以发给它哪些消息？基于这些考虑，FileLogger组件应该实现两种接口：Lifecycle（生存期接口）和LoggerBase（功能接口）。

Inversion of Control（IOC）这个模式定义的是，组件总是通过外部进行管理的。组件需要的信息总是来源于外部，实际上组件在生存期的各个阶段都是被创建它的组件管理的。在Tomcat4.0中就是通过这种组件之间的相互控制和调用实现各个功能的。

按照这些模式分析得到的Tomcat4.0中的组件是既有共性又有特性。共性是Lifecycle接口，特性是不同的功能接口。其中生存期接口处理组件的整个生存期中的各个阶段的事件,功能接口提供给其他的组件使用。

具体的功能如何实现我在这里不多介绍了，我主要介绍一下Tomcat4.0中组件的Lifecycle接口的设计。Lifecycle接口实现了组件的生存期管理，控制管理和通讯。创建一个软件组件和创建一个JavaBean对象一样，可以参考JavaBean进行理解。我通过一个模拟的 Lifecycle接口组件的类图来描述。(见图三)

图?3.?Lifecycle接口组件类图

对模拟的Lifecycle接口组件的类图的说明

1. Lifecycle Interface(接口)定义一组组件通讯的Message(消息)。
2. 组件实现Lifecycle接口，组件内部定义一个LifecycleSupport对象。需要和该组件通讯的其他组件必须实现LifecycleListener接口，该组件通过add/removeLifecycleListener方法管理需要通讯的其他组件。
3. 组件内部状态改变时如果需要和其他组件通讯时，通过LifecycleSupport对象的fireLifecycleEvent方法通知其他组件。
4. 其他组件通过lifecycleEvent方法获得通知的消息。LifecycleEvent对象是从java.util.EventObject派生的。
5. 当然在组件设计和实现中我们也可以直接使用JavaBeans中已经提供的的类如：java.beans.PropertyChangeListener；java.beans.PropertyChangeSupport这样可以获得更多的功能特性支持。

通过上面的分析我们可以看到组件成为Tomcat4.0中的核心概念，系统的功能都是通过组件实现的，组件之间的通讯构成了系统的运行控制机制。我们把 Tomcat3.3中模块化的链状控制机制和Tomcat4.0的面向组件的设计进行比较，就会发现Tomcat4.0在设计思想上软件组件的概念非常明确。Tomcat4.0和Tomcat3.3最主要的区别就在于此。至于面向对象和面向组件的关系和区别，我在这里就不介绍了，有兴趣的朋友可以找到很多这方面的资源。

从Tomcat源码中得到高效的软件组件

Tomcat不但为我们提供了设计和实现系统时的新思路，同时因为它是由组件或者模块构成的，所以它还为我们提供了大量可用的高效软件组件。这些组件都可以在我们的程序开发中使用。我简单列举一些，需要时可以直接从源码中取得。

• 一些特殊集合类数据结构如池、队列、缓存等可用于服务端开发。 "src"share"org"apache"tomcat"util"collections
• 一个简单的钩子（Hooks）机制的实现。 src"share"org"apache"tomcat"util"hooks
• 一个简单线程池（ThreadPool）的实现。 src"share"org"apache"tomcat"util"threads
• 组件Lifecycle接口的设计和实现。 "src"catalina"src"share"org"apache"Catalina
• 常用的日志信息的管理（Logger）的实现。 src"catalina"src"share"org"apache"catalina"logger
• 对xml格式的配置信息进行处理（XmlMapper）的实现。 src"catalina"src"share"org"apache"catalina"util"xml
• 对socket通讯的高级管理和实现（net）。 "src"catalina"src"share"org"apache"catalina"net

通过以上对Tomcat的简单的介绍，我们可以看出，作为一个开放源码的项目，Tomcat不但为我们提供了一个应用的平台，同时它还为我们提供了一个学习和研究设计模式、面向组件技术等理论的实践平台。