WebX配置文件、启动与响应流程

https://www.cnblogs.com/wzyxidian/p/5590813.html

这里以经典的petstore项目为例。首先看配置文件。当然先看web-app文件夹了.web -app下的文件和文件夹文件夹下有common，home，store和user四个文件夹以及web .XML等6个XML文件。它们的作用是什么呢？当然是配置的网络容器了。这么多文件又是如何相互配合的呢？其中肯定是有相互的引用的。下面就来看一下首先。 。是的web.xml文件文件文件文件文件文件文件文件文件这是最重要的一个文件，网页应用启动时就要根据其中的内容来加载容器了看一下这个文件中的内容：首先是三个上下文，分别配置了日志系统的根目录，日志级别和日志的编码格式这些就不用多说了接下来是两个重要的配置：监听一个是LogConfigurationListener，是日志相关的;一个是WebxContextLoaderListener，这个与应用的容器相关的它们的作业和工作原理稍后再来分析.Listener之后是两个滤波器，也是分别和 志容相：硒TLO ggin克精读textFilter和WebxFrameworkFilter然后是两个filtermapping和两个小服务程序映射。

现在来看一下WebxContextLoaderListener。顾名思义，这是一个Listener，一个监听器。看这一个监听器是实现了ServletContextListener接口的。其中定义了两个方法在前者实现了，一个是public void contextInitialized（ServletContextEvent sce）;一个是public void contextDestroyed（ServletContextEvent sce）;显然两个方法的参数是事件，而函数的作用就是参数传进来的事件作出反应：一个是容器“initialized”，一个是“Destroyed”，也就是说，在网络应用启动和销毁的时候作出自己的响应，也就开始了和结束了容器的生命。然后是两个过滤器，我们来看一下WebxFrameworkFilter。配置文件里定义了过滤器的名字，过滤器级和两个初始化参数重要的是过滤器类：.WebxFrameworkFilter，其作用当然是对请求作过滤了过滤的规则则是在两个初始化参数中配置的这个类继承了FilterBean类当应用启动的时候，其NIT 这个函数中有一个功能就是取得了webxRootController根据什么获取呢，这里就用到了webx.xml以及WEBX - * .xml的了（本文的目的是为了分析配置文件之间的关系）.webx.xml和webx - *

.XML的语法相同，作用类似，内容也非常相似对应的是父应用和子应用先看webx.xml的内容首先是几个进口把它的几个文件引用进来了：..常见/ WEBX组分 - - 的ROOT.xml，公共/流水线exception.xml，公共/ resources.xml中，公共/ uris.xml，公共/模板data.xml中这样就把公共文件夹下7个文件中的5个引用进来了。另外通过类路径资源，把其它模块下的三个XML文件也引用进来了。这样在应用中就会把所有的XML文件全部利用上了。以前老没有看到其他文件有什么用，这次终于明白了。但是还有一个问题，共同的文件夹下有7个文件，这里仅仅导入进来了5个，还有两个（pipeline.xml和component.xml文件文件文件文件文件文件文件文件文件文件文件文件）呢？它们应用的配置文件（WEBX - * XML）中引用到了下面看一下每个配置文件的作用：。管线exception.xml定义了对异常的响应，即遇到异常时 哪个个面应; resources.xml中中中中中中中中中中中则定义了各种源及其响应的装载机; uris.xml定义了发生内部或外部重定向时URI的构造; WEBX分量和根则定义了页面渲染的相关功能以及对URL后缀的映射; WEBX组分则将框架提供的服务提供给了应用; 管道是起到阀门作用的数据流管道了，这里决定了请求的方向。此外对应着家庭，用户和卖场三个文件夹下都有一个form.xml。这里的form.xml当然为应用提供表单验证的功能。

至此，所有的配置文件的功能以及相互之间引用的关系已经分析完了。如果想对其进行扩展的话，可以自己写一个XML文件，再被其他XML文件所导入就可以了。对配置文件的分析就到这里了，下面再看一下请求数据流程（这一部分很多地方可以找到介绍的）：一个请求对应的URL的地址部分可以分成三个部分：服务器地址，网络项目和子应用当然服务器的地址就决定了这个请求是否到本台服务器;然后再分发给某一个网络应用比如说的的的的的的的的的的的PetStore就求最后送到了子应用或者具体的页面上了当请求到达一个网络应用内部的时候，首先请求的后缀会根据WEBX组分和 - 的ROOT.xml中的配置做一次映射之后请求就进入管道，其具体的流向就交由pipeline.xml决定了.pipeline中定义的操作首先是初始化tuibine，然后依次为日志上下文，URL分析获取目标（比较抽象 一个体概要），csrfT oken的检查和权限检查;最后就是按照目标来分发流向了。以后缀为null（target-extension-condition extension =“null”）的情况为例：首先是perforAction处理表单数据;然后是performTemplateScreen填充页面内容; ……最后是renderTemplate渲染页面其中操作和屏幕对应的类分别在**模块[动作，屏幕]中查找的规则是由内到外，由特定到默认的类名了其中请求的流动过程中可能会发生重定向。这个时候为了避免硬编码中构造URL的不便，uris.xml就派上用场了。此外在学习的过程中还遇到了占位符的问题，在请教师兄时候才明白。例如WEBX .xml中的“$ 1”，就是说这是一个占位符，可以被前边的占位符定义的内容来替换。