**
最近几天一直在看Spring的Ioc和AOP的源码介绍，还有Webx的使用。看Spring的源代码让人眼花缭乱，webx的配置文件也会让人感觉错综复杂无从下手。今天把之前看到的想到的webx相关的内容记下来，也当为自己的学习做一个小小的总结。
这里以经典的petstore项目为例。
首先看配置文件。当然先看web-app文件夹了。 
文件夹下有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定义的内容来替换。