webx请求处理过程
在web.xml配置主控制器 com.alibaba.webx.WebxControllerServlet，映射对应的请求类型。对应的请求在其父类AbstractWebxControllerServlet的doGet中处理(doPost请求调用doGet同样处理)，其处理过程如下:
经过以上几个步骤完成请求的响应。下面具体看下主要步骤
RunData组装过程
getRunData(request, response)的处理逻辑如下:
getWebxController()取得的是初始化创建的WebxLoader, getRunDataService()在WebxLoader 读取配置的时候在configureWebxController()这个步骤被创建进来的，通过以下代码获得RunDataService
其在webx-default.xml中配置如下:
  
即DefaultRunDataService，其getRunData代码如下:
super.getRunData(request, response, config) 如下:
getRequestContext在其父类的RequestContextChainServiceImpl中，其代码如下:
从上面代码可以看出，RunData是被一系列的RequestContextFactory使用 装饰模式层层包装创建出来的，其依次调用以下6个包装工厂的包装方法
BufferedRequestContextFactory
LazyCommitRequestContextFactory
ParserRequestContextFactory
SessionRequestContextFactory
SetLocaleRequestContextFactory
RunDataFactory
这些包装工厂加载过程详见"2.1.1 RequestContext包装过程".
通过调用RequestContextFactory
requestContext = factory.getRequestContextWrapper(requestContext);
获取requestContext，以下是各包装类对应实现及作用：
  • BufferedRequestContextFactory 将requestContext包装成BufferedRequestContext（具体子类BufferedRequestContextImpl），对response输出流进行缓存操作；
  • LazyCommitRequestContextFactory 将requestContext包装成LazyCommitRequestContext（具体子类LazyCommitRequestContextImpl),支持延迟提交response；
  • ParserRequestContextFactory 将requestContext包装成ParserRequestContext（具体子类ParserRequestContextImpl)，支持自动解析request parameters和cookie parameters，并透明地处理upload请求的request context实现；
  • SessionRequestContextFactory将requestContext包装成SessionRequestContext（具体子类SessionRequestContextImpl),支持session,其覆盖getSession等方法；
  • SetLocaleRequestContextFactory 将requestContext包装成SetLocaleRequestContext（具体子类SetLocaleRequestContextImpl)，设置区域和编码字符集；
  • RunDataFactory 将requestContext包装成RunData（具体子类由配置rundata.class对应值决定，这里是ChinaRunData)，代表servlet运行时的信息；
创建完成后，依次调用requestContext.prepare()方法。
在后续可以向下转型，使用具体的包装，如RunData。这样设计有利于后续扩增。
RunData运行时数据结构如下图：
RequestContext包装过程
RequestContext包装类是被各自的RequestContextFactory创建出来的，各RequestContextFactory分别在DefaultRunDataService、RequestContextChainServiceImpl初始化。
首先看下DefaultRunDataService加载RequestContextFactory过程：
DefaultRunDataService首先判断是否兼容（rundata被升级成RequestContext的一个实现，所以在这打了个补丁），这里以配置文件中是否有request.${属性}.class键为依据。由于我们在RunDataService中配置
<property name="request.buffered.class" value="com.alibaba.webx.request.context.buffered.BufferedRequestContextFactory"/>
等属性，所以不作兼容处理。转而由配置文件中加载，可以看到RunDataService (webx-default.xml)配置的属性如下:

如果没有这些request.[name].class属性，则DefaultRunDataService初始化的时候会在configuration中设置以下属性
request.buffered.class : com.alibaba.webx.request.context.buffered.BufferedRequestContextFactory
request.lazycommit.class : com.alibaba.webx.request.context.lazycommit.LazyCommitRequestContextFactory
request.parser.class : com.alibaba.webx.request.context.parser.ParserRequestContextFactory
request.parser.autoupload : ...
request.parser.unescape.parameters : ...
request.parser.url.case.folding : ...
request.locale.class : com.alibaba.webx.request.context.locale.SetLocaleRequestContextFactory
下一步强制在configuration中增加rundata factory配置
request.rundata.class : ...RunDataFactory
且增加request.rundata.rundata.class，该键对应值从配置文件rundata.class中取得，如果没有配置这个属性，则默认取DefaultRunData，这里我们配置为
<property name="rundata.class" value="com.alibaba.china.common.webx.service.rundata.ChinaRunData"/>
所以最后键值对为
request.rundata.rundata.class : ...com.alibaba.china.common.webx.service.rundata.ChinaRunData
注意: RunDataService在webx-turbine-default.xml（该配置在对应的scheme实现中，这里是turbine实现，因此在toolkit.webx.turbine-2.0.jar对应的com.alibaba.turbine.scheme包下可找到该配置文件，可参见"1.2 scheme的实现类加载过程"）中配置如下：
<! - Webx核心service之一，用来保存每一个HTTP请求的状态。需要PoolService和UploadService的支持。->
<service name="RunDataService" class="com.alibaba.webx.service.rundata.DefaultRunDataService">
<property name="rundata.class" value="com.alibaba.turbine.service.rundata.DefaultRunData"/>
</service>
如果后面未进行配置覆盖，则默认的就是DefaultRunData。
最后调用父类RequestContextChainServiceImpl的初始化方法，其把这些键值设置到factories中，其最后值包括如下:
BufferedRequestContextFactory
LazyCommitRequestContextFactory
ParserRequestContextFactory
SessionRequestContextFactory
SetLocaleRequestContextFactory
RunDataFactory
请求处理过程 handleRequest
这里请求的处理过程是使用类链式的处理，spring、webwork、tomcat也使用类似的处理机制!webx中链式处理机制称为pipeline,该机制引用源代码中的注释解释如下：
pipeline： 代表一组顺序执行的操作，好象液体流过一根管道一样
_Valve: _ 代表pipeline中的一个"阀门" Valve这个词的意思就是真实世界中的水管中的阀门，它可以控制和改变液体的流向
pipeline中可以根据条件决定是否执行某步操作，典型的一个pipeline配置如下：
在webx-default.xml中配置一个pipeline服务如下：
<service name="PipelineService"
class="com.alibaba.service.pipeline.DefaultPipelineService">
<property name="pipeline.default.descriptor" value="elf/pipeline.xml" />
</service>
其中pipeline.default.descriptor指定了pipeline配置文件所在，其配置如下：

以上配置的在请求的处理过程中会按顺序执行，具体实现过程如下：

一般配置的value如下：
com.alibaba.service.pipeline.TryCatchFinallyValve
com.alibaba.service.pipeline.DefaultPipeline
com.alibaba.turbine.pipeline.SetLoggingContextValve
com.alibaba.turbine.pipeline.SetLocaleValve
com.alibaba.pivot.common.hessian.valve.HessianRemoteCallValve
com.alibaba.china.common.webx.valve.SessionValve
com.alibaba.turbine.pipeline.AnalyzeURLValve
com.alibaba.elf.web.common.SSOValve
com.alibaba.bopshared.valve.PermissionValve
com.alibaba.china.common.webx.valve.SecurityCheckValve
com.alibaba.turbine.pipeline.ChooseValve
com.alibaba.turbine.pipeline.RedirectTargetValve
com.alibaba.turbine.pipeline.SetLoggingContextValve
各Value的作用分别如下：
  • SetLoggingContextValve
利用 NDC 和 MDC 的机制，简单快捷的为Web应用日志增加用户跟踪，具体可参考 http://www.ibm.com/developerworks/cn/web/wa-lo-usertrack/index.html
  • SetLocaleValve
设置编码
<valve class="com.alibaba.turbine.pipeline.SetLocaleValve" defaultLocale="zh_CN" defaultCharset="GBK"/>
  • HessianRemoteCallValve
拦截hessian请求,默认以/remoting开头被该拦截器处理
  • SessionValve
  • AnalyzeURLValve
根据URL的内容设置rundata相关属性
使用MappingService，将target的后缀转换成统一的内部后缀,将字符串转换成camel case
StringUtil.toCamelCase(null) = null
StringUtil.toCamelCase("") = ""
StringUtil.toCamelCase("aBc") = "aBc"
StringUtil.toCamelCase("aBc def") = "aBcDef"
StringUtil.toCamelCase("aBc def_ghi") = "aBcDefGhi"
StringUtil.toCamelCase("aBc def_ghi 123") = "aBcDefGhi123"
在webx中，需要将模板名转换成相应的module类名或layout模板名，代码如下：

getMappingService()获取DefaultMappingService，其extension.input定义如下:
<property name="mapper.extension.input">
<property name="class" value="com.alibaba.turbine.service.mapping.mapper.ExtensionMapper"/>
<!-- 默认后缀 -->
<property name="extension." value=""/>
<!-- JSP -->
<property name="extension.jhtml" value="jsp"/>
<property name="extension.jsp" value="jsp"/>
<property name="extension.php" value="jsp"/>
<!-- Velocity -->
<property name="extension.htm" value="vm"/>
<property name="extension.vhtml" value="vm"/>
<property name="extension.vm" value="vm"/>
</property>
即通过getMapper("extension.input"). getMappedName("/common/index.htm")进行后缀的转换，转换逻辑在ExtensionMapper中。 如果映射规则存在，则替换后缀htm后缀为vm，如果以/结尾，就不加后缀,设置完成后放到runData的target属性中
如果在上面未找到后缀转换信息，如.json的后缀，那么ExtensionMapper会直接返回该后缀，不进行转换
ExtensionMapper 转换后的target比较重要，后续pipeline的ChooseValve在选择Module处理的时候会根据该后缀判断由哪些value处理。
  • PermissionValve
执行action screen权限检查
数据提交commitRunData
在AbstractWebxControllerServlet提交数据如下：
调用RequestContextChainServiceImpl的commitRequestContext方法：

 
此处的调用过程刚好跟RequestContext包装过程顺序相反，依次调用每个包装类的提交方法
Module加载及响应
在2.2节中 采用pipeline机制处理请求，其中有一个是value是ChooseValve，如下：
<valve class="com.alibaba.turbine.pipeline.ChooseValve" label="processModule">
<when extension="jsp, vm">
<valve class="com.alibaba.turbine.pipeline.PerformActionValve" actionParam="action"/>
<valve class="com.alibaba.turbine.pipeline.PerformScreenTemplateValve"/>
</when>
<when extension="json">
<valve class="com.alibaba.china.common.webx.valve.PerformJsonValve"/>
</when>
<when extension="do">
<valve class="com.alibaba.turbine.pipeline.PerformActionValve" actionParam="action"/>
<valve class="com.alibaba.turbine.pipeline.PerformScreenValve"/>
</when>
</valve>
ChooseValve中覆盖了
public TagLibrary getCustomizedTagLibrary() 方法，该方法定义在Customizable接口中，以支持jelly.TagLibrary的解析。 
通过以上标签解析将对应的value设置到成员变量conditions 中，pipeline中处理的时候调用ChooseValve的invoke方法，该方法遍历conditions中，查找符合条件的condition，执行子value的调用。这里符合条件如TargetExtensionCondition，该类用来判断runData中的target后缀是否符合配置文件中的extension属性值，如果符合，则进行这些value调用。
即如果是以htm、html结尾的url， 则PerformActionValve、PerformScreenTemplateValve会被调用。
PerformActionValve 首先会判断请求参数中是否包含默认的action键，如果没有，直接返回空。否则开始跟ModuleLoaderService交互，取得对应的action module,具体实现代码如下：
以上代码调用具体由DefaultModuleLoaderService的
public Module getModuleInternal (String moduleType, String moduleNameFQ)
方法完成，该方法完成对应类型和module的加载，该方法实现代码如下：

继续看下loadModule(moduleType, moduleName)的加载过程，其通过ModuleFactory的工厂方法创建对应Module,实现如下：

ModuleFactory是通过查找Configuration中module.factory的配置信息取得的，
moduleLoaderService的配置信息如下：

其module.factory为com.alibaba.turbine.service.moduleloader.factory.
DefaultModuleFactory，且其对应的key 为default.
若其他地方未在配置module.factory，则程序中默认取DefaultModuleFactory创建Module，其通过 package + moduleType + moduleName作为类名进行module的加载。
package 通过module.packages取得，而module.packages在各自模块的webx.xml配置如下：
<service name="ModuleLoaderService">
<property name="module.packages">
<value>com.sylinxsoft.webxdemo.web.module1.module</value>
</property>
</service>
因此请求一个action如Hello,则最终会加载的类为com.sylinxsoft.webxdemo.web.module1.module.action.Hello。
程序中使用遍历每个模块，直到加载到对应的类则停止尝试加载。
注 ： 如果模块比较多，会有效率问题？
定位到该module后，判断该类是否是抽象的，如果是，则用CGLIB创建子类。否则直接newInstance。生成实例后，通过resolver注入相关属性，resolver可以通过module.ref.resolver.class在配置文件中指定，如果没有指定，则采用默认的ResolverWrapper，目前还有另一种选择实现是SpringReferenceResolver
实例化后调用module.init进行初始化。
每个module必须实现Module接口，其已有实现如下图：

其有个主要方法是
void execute(RunData rundata)，该方法就是用来处理对应请求
注 ： 虽然每个module在ModuleFactory每次都是被重新创建并调用其初始化方法的，但是由于外层如果指定cacheEnabled，则后面都是从缓存中取得。此时该module就要考虑线程安全问题。
TemplateAction
一般Action都继承TemplateAction,其父类为ActionEvent, 其execute的执行逻辑如下：
取得key=eventSubmit_do${event}, 将do${event}方法作为具体的调用目标，如果找不到该方法，则尝试使用默认的doperform。这里使用反射进行方法查找调用。
执行反射的参数获取为
Object[] methodArgs = getEventMethodParameters(rundata);
该方法在TemplateAction中覆盖为

因此最终调用module的方法为
do${event}（RunData rundata, TemplateContext context)
其中TemplateContext是从pullService中取得，关于TemplateContext的详细获取过程，在后续章节中说明
从TemplateAction 派生的对应module类的do${event}（RunData rundata, TemplateContext context)方法最终会响应请求，在这个方法里面通常会使用命令模式和其他容器交互(如spring容器、Ejb容器)，交互后返回Result，将Result相关结果设置到TemplateContext中，
NoTemplateModule
纯数据输出的Module模型（不需要模板）, 该类Module主要为无模板页面显示内容,一般用于ajax内容输出
查看NoTemplateModule抽象类方法，其execute(RunData rundata)方法如下：

刚开始看到该方法比较奇怪，后来回头查看pipeline.xml的配置才明白，原来NoTemplateModule的请求需要以json结尾，pipeline.xml的部分配置如下: 
由上配置可以看出json结尾是由PerformJsonValve进行处理
注意json后缀是经过AnalyzeURLValve的MappingService处理过的，如果在MappingService里面未配置，则前台页面配置的url就是以json结尾。
下面具体看下PerformJsonValve处理逻辑
PerformJsonValve继承自AbstractNoTemplateVavle，在AbstractNoTemplateVavle中，其invoke方法如下：

performNoTemplateOutput(RunData rundata) 处理逻辑如下：

由此NoTemplateModule具体调用的是
execute(RunData rundata, NoTemplateContext context)
方法，其直接由具体的Module实现。
TemplateModule
TemplateModule 有模板内容输出，继承TemplateModule的有TemplateControl、TemplateLayout、TemplateScreen，TemplateModule主要是作为view来显示内容的。
其执行过程如下：

TemplateModule执行过程大概分为两个过程：
  • 执行具体TemplateModul的execute方法：
具体的execute(RunData rundata, TemplateContext context)由子类提供，该方法通常会采用命令模式与AO层交互，将AO层返回的Result相关值设置到TemplateContext，该TemplateContext会在后续被具体的模板解析引擎使用。
  • 渲染模板，将结果写回rundata中：
mergeTemplate(rundata, template, context)主要跟模板服务TemplateService交互，渲染对应的模板
这里获取的template名称是在PerformScreenTemplateValve中被设置成和target一样的值.另外如果模板名称没有后缀名，则程序中会取配置文件中的
<property name="default.extension" value="vm" />
作为其后缀名去查找模板。
TemplateService会委托TemplateEngineService完成具体模板的加载与渲染，TemplateEngineService在程序中查找已经注册的模板引擎，每个模板引擎初始化的时候会获取TemplateService，然后将自身注册到TemplateService的模板管理器重，注册的时候会取配置文件中的template.extension值作为key进行自身映射，如果没有，则取TEMPLATE_EXTENSIONS变量的值作为默认，在VelocityService中其默认值为vm.典型的Velocity模板解析引擎配置如下:
<service name="VelocityService"
class="com.alibaba.service.velocity.DefaultVelocityService"
earlyInit="true">
<property name="input.encoding" value="GBK" />
<property name="parser.pool.size" value="100" />
<property name="velocimacro.library" value="macros.vm"/>
<property name="eventCartridge.classes"
value="com.alibaba.china.fasttext.security.velocity.SecurityReferenceInsertionEventHandler" />
</service>
在配置文件中可以配置多种模板解析引擎,如ftl等。
模板引擎负责查找、解析渲染模板（具体的模板引擎查找解析过程不尽相同，VelocityService等详细处理过程见后面章节），模板被解析渲染后会将结果写入到rundata.getResponse().getWriter()中，在commitRunData阶段才将数据写到response输出流中。
与Spring容器交互
通常screen、action、control是在Webx中管理, AO、BO、DO、DAO及其它service是在spring容器中管理,web层和业务逻辑层传递VO、DO（对web层污染）数据。
中间消息传递(调用)使用命令模式，可具体参考" 业务层框架Command Pattern指南.doc"
以下是具体实现：
在CommandDispatcherSelector中和spring容器交互

CommandDispatcher具体子类是CommandDispatcherLogic,其execute如下:


以事件的方式调用ao的方法