第九章:Servlet工作原理解析

9.1 从Servlet容器说起

Servlet和Servlet容器的关系,就像枪和子弹的关系,彼此依存又互相独立发展,这一切都是为了适应工业化生产。从技术角度来说,是为了解耦,通过标准化接口来互相协作。

所以说,接口是连接Servlet和Servlet容器的关键。那么我们就从它们的接口说起。

以Tomcat为例:

下图为Tomcat的容器等级:

第九章:Servlet工作原理解析

Wrapper为Servlet在容器中的包装类。Context直接管理包装类Wrapper.

上图可以看出,Tomcat容器分为4个等级(Container容器,Engine,Host,Context),真正管理Servlet的容器是Context容器。一个Context对应一个web工程。

Servlet容器的启动过程

选择的是Tomcat7自带的examples web工程。(书中代码)

创建了一个Tomcat实例并新增了一个web应用,然后启动Tomcat并调用其中一个HelloWorldExample Servlet。

Tomcat tomcat = getTomcatInstance();
File appDir = new File(getBuilderDirectory(),"webapps/examples");
tomcat.addWebapp(null,"/examples",appDir.getAbsolutePath());
tomcate.start();
ByteChunk res = getUrl("http://localhost:"+getPort()+
"/examples/servlets/servlet/HelloWorldExample");
assertTrue(res.toString().indexOf("<h1>Hello </h1>")>0);

关于以上代码中的addWebapp{

  创建一个StandardContext容器,并且给这个Context容器设置必要的参数(url,path)。url和path分别代表这个应用在Tomcat中的访问路径和这个应用的实际物理路径。

  创建ContextConfig,用Context来接收(多态),这个类会负责整个web应用配置的解析工作。

  然后将ContextConfig添加到StandardContext的LifecycleListener中。

  配置完后将Context容器加到父容器Host中。

}

接下来调用Tomcat的start方法启动Tomcat。

Tomcat的启动逻辑是基于观察者模式设计的。所有的容器都会继承LifecycleListener接口。它管理着容器的整个生命周期。所有容器的修改和状态的改变都会由它去通知已经注册的观察者(listener)

ContextConfig类的init方法主要完成以下工作:

  创建用于解析XML配置文件的contextDigester对象。

  读取默认的context.xml配置文件,如果存在则解析它。

  读取默认的Host的文件,如果存在则解析它

  读取默认的Context自身的配置文件,如果存在则解析它

  设置Context的DocBase。

ContextConfig的init方法完成以后,Context容器就会执行startInternal方法,主要包括如下:

  创建读取资源文件的对象

  创建ClassLoader对象

  设置应用的工作目录

  启动相关的辅助类,如logger,realm,resources等

  修改启动状态,通知感兴趣的观察者

  子容器的初始化

  获取ServletContext并设置必要的参数

  初始化"load on startup"的Servlet

web应用的初始化工作:

web应用的初始化工作是在ContextConfig的configureStart方法中实现的,应用的初始化主要是解析web.xml文件。

Tomcat →globalWebXml→hostWebXml→examples/WEB-INF/web.xml。  (web.xml文件的各个配置项将会被解析成相应的属性保存在WebXml对象中)

如果当前应用支持servlet 3.0,还会完成额外9项工作。

接下来将WebXml对象中的属性设置到Context容器中。这段代码在WebXml的configureContext方法中。(这段代码将Servlet包装成了StandardWrapper并添加在了Context容器中)

把Servlet包装成StanderdWrapper的原因:

  这里的StanderWrapper是Tomcat容器的一部分,它具有容器的特征,而Servlet作为一个独立的Web开发标准,不应该强耦合在Tomcat中。

9.2 创建Servlet实例

如果Servlet的load-on-startup配置项大于0,那么在Context容器启动时就会被实例化。

conf/web.xml中定义了两个Servlet,分别是DefaultServlet和JspServlet,他们的load-on-startup分别是1和3。当tomcat启动时,他们两个都会启动。

创建Servlet实例的方法是从Wrapper.loadServlet开始的

Wrapper.loadServlet (获取servletClass)→交给InstanceManager→创建一个基于servletClass.class的对象。

初始化Servlet

StandardWrapper的initServlet方法{

  调用Servlet的init方法

  将StanderdWrapperFacade作为ServletConfig传给Servlet。

}

9.3 Servlet体系结构

与Servlet主动关联的三个类:ServletConfig     ServletRequest      ServletResponse

ServletConfig在Servlet初始化的时候就传给Servlet了。

  ServletConfig里面的方法可以获取一些Servlet的配置属性。

后两个是在请求达到时调用Servlet传递过来的。

  Servlet的运行模式是一个典型的握手型交互模式。就是说,两个模块为了交换数据通常都会准备一个交易场景,这个场景一直跟随这个交易过程直到这个交易完成为止。交易场景的初始化是根据这次交易对象指定的参数来定制的。

  交易场景就由ServletContext来描述,定制的参数集合就由ServletConfig来描述。

  ServletRequest和ServletResponse通常作为运输工具来传递交互结果。

init时,StanderdWrapperFacade作为ServletConfig传给Servlet,那么ServletConfig到底是个什么对象呢?

  StanderdWrapper和StandardWrapperFacade都实现了ServletConfig接口。而StandardWrapperFacade是StandardWrapper的门面类。这个类传给Servlet的作用是保证从StandardwWrapper中拿到的ServlertConfig所规定的的数据,而又不把ServletConfig不关心的数据暴露给Servlet。

  同理:在Servlet中拿到的ServletContext的实际对象也是ApplicationContextFacade对象。作用和上面相同。

  同理:在Servlet中拿到的Request和Response类也是门面类RequestFacade和ResponseFacade。(这里多了几步操作)

  这里使用的都是门面设计模式。

9.4 Servlet如何工作

  用户从浏览器向服务器发起的一个请求通常会包含如下信息:http://hostname:port/contextpath/servletpath   ,hostname和port用来与服务器建立TCP连接。后面的URL才用来选择在服务器中哪个子容器服务用户的请求。那么服务器是如何根据这个URL来到达正确的Servlet容器呢?

  在Tomcat 7 中很容易解决,这种映射专门交给了一个叫Mapper的类来完成。这个类保存了Tomcat类的Container容器中的所有子容器信息。在Request类进入Container容器之前,Mapper将会根据这次请求的hostname和contextpath将Host和Context容器设置到Request 的MappingData属性中。所以,在Request进入Container容器之前,对于它要访问哪个子容器就已经确定了。

  那么,Mapper中是怎么拥有容器的完整关系的?

  MapperListener的init()方法{

    将MapperListener类作为一个监听者加到整个Container容器的每个子容器中。这样只要任何一个容器发生变化,MapperListener都会被通知到。

    同时,MapperListener的Mapper属性也会被更改。

  }

Request请求是如何到达最终的Wrapper容器的呢(查资料 结合书  再来填坑)

  接下来,该执行Servlet的service方法了。

  通常情况下,我们自己定义的Servlet并不直接去实现Servlet接口,而是去继承更简单的HttpServlet类或者GenericServlet类,我们可以有选择的覆盖相应的方法完成要实现的工作。

  现在的web应用很少直接将交互的全部页面用Servlet实现,而是采用更加高效的MVC框架来实现。这些MVC框架的基本原理是将所有的请求都映射到一个Servlet,然后去实现service方法。这个方法也就是MVC框架的入口。这个博客讲的很好

  当Servlet从Servlet容器中移除时,也就表明Servlet的生命周期结束了。destory()方法开始被调用。

9.5 Servlet中的Listener

  Listener是基于观察者模式设计的

  能够方便地从另一个纵向维度控制程序和数据。目前Servlet提供了6种两类事件的观察者接口。

第九章:Servlet工作原理解析

事实上,这6个Listener都继承了EventListener接口。

注意:ServletContextListener在容器启动后就不能再添加新的了,因为它所监听的事件已经不会再出现了。

9.6 Filter如何工作

使用:通过<filter>和<filter-mapping>组合使用Filter。

Filter除了提供request和response对象外,还提供了一个FilterChain对象。

第九章:Servlet工作原理解析

而Filter的实现类,是用户自定义的。只需要实现Filter接口中定义的三个接口就行。

  init(FilterConfig):初始化接口。与Servlet中的init(ServletConfig)基本一样。可以获取到ServletContext对象,还能获取到在<filter>下配置的<init-param>参数值

  doFilter(ServletRequest,ServletResponse,FilterChain)每个用户请求进来的时都会被调用,在service方法之前被调用。FilterChain代表当前的整个请求链。这里是责任链设计模式。

  destory:Filter容器被销毁时调用。当web容器调用这个方法之后,还会再调用一次doFilter方法。

FilterChain的实现类ApplicationFilterChain里面有一个filters数组,保存了到达最终Servlet对象的所有Filter对象,每执行一个Filter对象,数组当前的计数都会加1。计数等于数组长度时,Servlet执行。

9.7 Servlet中的url-pattern

  Servlet和Filter在web.xml中都有<url-pattern>这个配置项。

  Servlet是通过Mapper类完成的,它在一个请求被创建时就已经匹配了。

  Filter的<url-pattern>是在创建ApplicationFilterChain对象时进行的。它会把所有的定义的Filter的url-pattern与当前的url匹配。匹配成功就将这个Filter保存到filters数组里,然后在FilterChain中调用。

  <url-pattern>的解析规则:精确匹配,路径匹配(前缀匹配),后缀匹配。

  web.xml加载时,会首先检查<url-pattern>配置是否符合规则。在StandardContext的validateURLPattern方法中检查的。不成功会报错。

  

  Servlet的匹配规则:精确匹配>最长路径匹配>后缀匹配。 注:一次请求只会成功匹配到一个Servlet。

  Filter的匹配规则:只要匹配成功,都会在请求链被调用。<url-pattern>不能用以“/”开头并且以“/*”结尾的根据路径映射,和以"*."开头的作为根据扩展名映射。

上一篇:WPF快速入门系列(5)——深入解析WPF命令


下一篇:爬虫必备 User-Agent 列表