标签：xml web 匹配 容器 对象 原理 解析 Servlet
一个context对应着一个web工程
一个wrapper对应一个servlet
1.1 Servlet容器启动过程
tomcat7以后支持嵌入式功能，可直接通过构建一个tomcat对象，调用start方法启动。
添加一个web应用会调用addWebapp方法，创建一个standardContext容器，
addWebapp(Host host,String url,String path)
host:context的上层容器
url:应用的访问路径
path:应用的实际路径Tomcat的启动逻辑是基于观察者模式设计的，所有的容器都会继承lifecycle接口，他管理容器的生命周期，所有容器的修改和状态的改变都会通知已经注册的观察者
最重要的一个配置类ContextConfig，它负责整个Web应用的配置文件的解析工作
ContextConfig的init方法主要完成以下工作：
创建解析XML配置文件的contextDigester对象
读取默认的context.xml文件，存在则解析它
读取默认的Host文件，存在则解析它
读取默认的Context自身配置文件，存在则解析它
设置Context的DocBase
ContextConfig的init完成，执行startInternal方法，主要包括：
创建资源文件对象，创建ClassLoader对象
设置对应的工作目录
启动相关辅助类
修改启动状态，通知感兴趣的观察者
子容器初始化
获取servletContext并设置必要的参数
初始化“load on startup” 的servlet
1.2 web应用初始化
Web应用初始化是在ContextConfig的configure方法实现的，主要是解析web.xml文件
Tomcat首先会找到globalWebXml,这个文件的路径是engine的工作目录下的org/apache/catalina/startup/NO_DEFAULT_XML或者conf/web.xml 。接着找hostWebXml, 这个文件在System.getProperty("catalina.base")/conf/${EngineName}/${HostName}/web.xml.default中。接着寻找应用配置文件/WEB-INF/web.xml。web.xml的各个配置项将会被解析成相应的属性保存在WebXml对象中，如果应用致辞servlet3.0，解析还将完成别的工作，比如注解的支持
servlet为什么要包装成StandardWrapper？
因为servlet是web的标准，不应强耦合在tomcat中，StandardWrapper是tomcat容器的一部分，具有容器特征
除了Servlet包装成StandardWrapper在Context容器外，其他所有的web.xml属性都被解析到Context中
1.3 创建Servlet实例
如果servlet的load-on-startup配置项大于0，那么context容器启动时就会被实例化
创建Servlet实例的方法是从Wrapper.loadSeervlet开始的，loadServlet方法要完成的就是获取servletClass，然后交给InstanceManager去创建一个机遇sevletClass.class的对象。如果配置了jsp-fle，那么这个servletClass就是JspServlet
2.1Servlet的体系结构
Servlet的规范基于ServletConfig，ServletRequest，ServletResponse这三个类运转
ServletConfig是在Servlet初始化的时候传给Servlet，而后两个值是在请求到达时调用Servlet传递过来的
StandWrapper 和 StandWrapperFacade都实现了ServletConfig的接口，StandWrapperFacade是StandWrapper的门面类，所以传给Servlet的是StandWrapperFacade对象，好处是只拿到感兴趣的数据，不会过多暴露数据
Tomcat接收请求，首先会创建org.apache.coyote.Request和Response ,这两个类是tomcat内部使用轻量级的类，只会简单解析，然后交给后续线程处理，对象很小，很容易被回收。接下来交给一个用户线程去处理这个请求，又会创建org.apache.catalina.connector.Request 和Response对象，这两个对象一直贯穿整个Servlet容器直到传给Sevelt，传递的也是门面类RequestFacade 和ResponseFacade
2.2 Servlet是如何工作的
一个请求：http://hostname:port/contextpath/servletpath
hostname 和port 是用来与服务器建立 TCP连接的 ，后面的url用来选择在服务器的哪个子容器中完成请求
如何确定哪个Servlet容器？
有一个mapper类保存Tomcat 和Container容器的所有子容器信息，进入Container之前Request会根据请求的hostname 和context 将host 和context容器设置到Request的mappingData属性中
2.3 Servlet中的Listener
基于观察者模式设计
servlet通过6种两类事件的观察者接口：
EventListeners: ServeltContextAtributeListener , ServeltRequestAtributeListener ,ServeltRequestListener, HttpSessionAtributeListener
LifecycleListeners: ServeltContextListener 和 HttpSessionListener
例如常用的ContextLoaderListener实际上就是实现ServletContextListener接口,容器加载时初始化Spring容器，ContextLoaderListener在contextInitialized方法中初始化Spring容器
public void contextInitialized(ServletContextEvent event) {
this.initWebApplicationContext(event.getServletContext());
}2.3 Filter如何工作
web.xml中配置<filter> 和 <filter-mapping> 使用filter 或者 实现filter接口
实现filter接口需要实现三个方法：
init：初始化
doFilter：请求来时调用，在servlet.service之前执行，使用责任链模式，可以通过FilterChain.doFilter将请求继续传递下去
destory：销毁时调用，注意，web容器调用这个方法以后，容器会再调用一次dofilter方法
Filter的核心是FilterChain对象，这个对象保存了最终Servlet对象的所有Filter对象，这些对象都在ApplicationFilterChain对象的filters数组，每执行一个filter，数组计数会加一，直到等于数组长度，执行完会执行Servlet，因此ApplicationFilterChain对象持有Servlet的引用
2.4 Servlet 中的url-pattern
servlet是通过mapper类映射，请求被创建时就已经匹配了
filter的url-pattern匹配在创建ApplicationFilterChain对象时进行，将所有filter的url-pattern与当前url匹配，匹配成功就保存到filters数组中
url-pattern匹配规则：
精确匹配：/foo.htm
路径匹配：/foo/*
后缀匹配：*.htm
Filter会将所有匹配成功的加入filters数组中
对于Servlet而言，多个匹配成功的话，优先级是：精确匹配优先，其次是最长匹配路径，最后是后缀匹配
标签：xml,web,匹配,容器,对象,原理,解析,Servlet 来源： https://blog.csdn.net/qq_42532161/article/details/120929785
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。