9.1 从Servlet容器说起
Servlet和Servlet容器的关系，就像枪和子弹的关系，彼此依存又互相独立发展，这一切都是为了适应工业化生产。从技术角度来说，是为了解耦，通过标准化接口来互相协作。
所以说，接口是连接Servlet和Servlet容器的关键。那么我们就从它们的接口说起。
以Tomcat为例：
下图为Tomcat的容器等级：
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种两类事件的观察者接口。
事实上，这6个Listener都继承了EventListener接口。
注意：ServletContextListener在容器启动后就不能再添加新的了，因为它所监听的事件已经不会再出现了。
9.6 Filter如何工作
使用：通过<filter>和<filter-mapping>组合使用Filter。
Filter除了提供request和response对象外，还提供了一个FilterChain对象。
而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>不能用以“/”开头并且以“/*”结尾的根据路径映射，和以"*."开头的作为根据扩展名映射。→