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

时间:2022-05-01 13:44:34

** 

最近几天一直在看Spring的Ioc和AOP的源码介绍,还有Webx的使用。看Spring的源代码让人眼花缭乱,webx的配置文件也会让人感觉错综复杂无从下手。今天把之前看到的想到的webx相关的内容记下来,也当为自己的学习做一个小小的总结。 
这里以经典的petstore项目为例。 
首先看配置文件。当然先看web-app文件夹了。 
WebX配置文件、启动与响应流程 
文件夹下有common、home、store和user四个文件夹以及web.xml等6个XML文件。它们的作用是什么呢?当然是配置web容器了。这么多文件又是如何相互配合的呢?其中肯定是有相互的引用的。下面就来看一下。 
首先是web.xml文件。这是最重要的一个文件,web应用启动时就要根据其中的内容来加载容器了。看一下这个文件中的内容: 
首先是三个context -param,分别配置了日志系统的根目录、日志级别和日志的编码格式。这些就不用多说了。接下来是两个重要的配置:Listener。一个是LogConfigurationListener,是日志相关的;一个是WebxContextLoaderListener,这个与应用的容器相关的。它们的作用和工作原理稍后再来分析。Listener之后是两个Filter,也是分别和日志与容器相关:SetLoggingContextFilter和WebxFrameworkFilter。然后是两个filtermapping和两个servletmapping。 
现在来看一下WebxContextLoaderListener。顾名思义,这是一个Listener,一个监听器。看一下源代码。而这一个监听器是实现了ServletContextListener接口的。其中定义了两个方法在前者实现了,一个是public void contextInitialized(ServletContextEvent sce);一个是public void contextDestroyed(ServletContextEvent sce);显然两个方法的参数是事件,而函数的作用就是对参数传进来的事件作出反应:一个是容器“initialized“,一个是“Destroyed“,也就是说,在web应用启动和销毁的时候作出自己的响应,也就开始了和结束了容器的生命。 
然后是两个Filter,我们来看一下WebxFrameworkFilter。配置文件里定义了filter-name、filter-class和两个init参数。重要的是filter-class:WebxFrameworkFilter,其作用当然是对请求作过滤了。过滤的规则则是在两个init参数中配置的。这个类继承了FilterBean类。当应用启动的时候,其init()方法被调用。这个函数中有一个功能就是取得了webxRootController。根据什么获取呢,这里就用到了webx.xml以及webx-*.xml了(本文的目的是为了分析配置文件之间的关系)。 
webx.xml和webx-*.xml的语法相同,作用类似,内容也非常相似。对应的是父应用和子应用。先看webx.xml的内容。首先是几个import。把其它几个文件引用进来了:common/webx-component-and-root.xml、common/pipeline-exception.xml、common/resources.xml、common/uris.xml、common/template-data.xml这样就把common文件夹下7个文件中的5个引用进来了。另外通过classpath资源,把其它模块下的三个XML文件也引用进来了。这样在应用中就会把所有的XML文件全部利用上了。以前老没有看到其他文件有什么用,这次终于明白了。但是还有一个问题,common文件夹下有7个文件,这里仅仅import进来了5个,还有两个(pipeline.xml和component.xml)呢?它们都应用的配置文件(webx-*.xml)中引用到了。下面看一下每一个配置文件的作用: 
pipeline-exception.xml定义了对异常的响应,即遇到异常时用哪个页面响应; 
resources.xml则定义了各种资源及其响应的loader; 
uris.xml定义了发生内部或外部重定向时URI的构造; 
webx-component-and-root则定义了页面渲染的相关功能以及对URL后缀的映射; 
webx-component则将框架提供的服务提供给了应用; 
pipeline则是起到阀门作用的数据流管道了,这里决定了请求的方向。 
此外对应着home、user和store三个文件夹下都有一个form.xml。这里的form.xml当然为应用提供表单验证的功能。 
至此,所有的配置文件的功能以及相互之间引用的关系已经分析完了。如果想对其进行扩展的话,可以自己写一个XML文件,再被其他XML文件所import就可以了。 
对配置文件的分析就到这里了,下面再看一下请求数据流程(这一部分很多地方可以找到介绍的): 
一个请求对应的URL的地址部分可以分成三个部分:服务器地址、web项目和子应用。当然服务器的地址就决定了这个请求是否到本台服务器;然后再分发给某一个web应用比如说petstore。最后就送到了子应用或者具体的页面上了。 
当请求到达一个web应用内部的时候,首先请求的后缀会根据webx-component-and-root.xml中的配置做一次映射。之后请求就进入管道,其具体的流向就交由pipeline.xml决定了。pipeline中定义的操作首先是初始化tuibine,然后依次为日志上下文、URL分析获取target(比较抽象的一个概念)、csrfToken的检查和权限检查;最后就是按照target来分发流向了。以后缀为null(target-extension-condition extension=”null”)的情况为例:首先是perforAction处理表单数据;然后是performTemplateScreen填充页面内容;最后是renderTemplate 渲染页面。其中Action和Screen对应的类分别在**.module.[action、screen]中。查找的规则是由内到外,由特定到默认的类名了。其中请求的流动过程中可能会发生重定向。这个时候为了避免硬编码中构造URL的不便,uris.xml就派上用场了。 
此外在学习的过程中还遇到了占位符的问题,在请教师兄时候才明白。例如webx.xml中的“$1“,就是说这是一个占位符,可以被前边的place-holder定义的内容来替换。