前言

　　本文继续讲解TOMCAT的请求原理分析，建议朋友们阅读本文时首先阅读过《TOMCAT源码分析——请求原理分析（上）》和《TOMCAT源码分析——请求原理分析（中）》。在《TOMCAT源码分析——请求原理分析（中）》一文我简单讲到了Pipeline，但并未完全展开，本文将从Pipeline开始讲解请求原理的剩余内容。

管道

　　在Tomcat中管道Pipeline是一个接口，定义了使得一组阀门Valve按照顺序执行的规范，Pipeline中定义的接口如下：

• getBasic：获取管道的基础阀门；
• setBasic：设置管道的基础阀门；
• addValve：添加阀门；
• getValves：获取阀门集合；
• removeValve：移除阀门；
• getFirst：获取第一个阀门；
• isAsyncSupported：当管道中的所有阀门都支持异步时返回ture，否则返回false；
• getContainer：获取管道相关联的容器，比如StandardEngine；
• setContainer：设置管道相关联的容器。

　　Engine、Host、Context及Wrapper等容器都定义了自身的Pipeline，每个Pipeline都包含一到多个Valve。Valve定义了各个阀门的接口规范，其类继承体系如图1所示。

图1　　Valve的类继承体系

这里对图1中的主要部分（LifecycleMBeanBase及Contained接口在《TOMCAT源码分析——生命周期管理》一文详细阐述）进行介绍：

• Valve：定义了管道中阀门的接口规范，getNext和setNext分别用于获取或者设置当前阀门的下游阀门，invoke方法用来应用当前阀门的操作。
• ValveBase：Valve接口的基本实现，ValveBase与Valve的具体实现采用抽象模板模式将管道中的阀门串联起来。
• StandardEngineValve：StandardEngine中的唯一阀门，主要用于从request中选择其host映射的Host容器StandardHost。
• AccessLogValve：StandardHost中的第一个阀门，主要用于管道执行结束之后记录日志信息。
• ErrorReportValve：StandardHost中紧跟AccessLogValve的阀门，主要用于管道执行结束后，从request对象中获取异常信息，并封装到response中以便将问题展现给访问者。
• StandardHostValve：StandardHost中最后的阀门，主要用于从request中选择其context映射的Context容器StandardContext以及访问request中的Session以更新会话的最后访问时间。
• StandardContextValve：StandardContext中的唯一阀门，主要作用是禁止任何对WEB-INF或META-INF目录下资源的重定向访问，对应用程序热部署功能的实现，从request中获得StandardWrapper。
• StandardWrapperValve：StandardWrapper中的唯一阀门，主要作用包括调用StandardWrapper的loadServlet方法生成Servlet实例和调用ApplicationFilterFactory生成Filter链。

　　有了以上对Tomcat的管道设计的讲述，我们下面详细剖析其实现。

　　在《TOMCAT源码分析——请求原理分析（中）》一文中讲到执行管道的代码如代码清单1所示。

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com

原标题：Tomcat源码分析——请求原理分析（下）

关键词：tomcat