struts1源码分析(三)请求处理主线
在初始化主线一文中，我们详细分析了框架的初始化过程。本文将从Struts的另外一条主线出发，分析框架的实现原理。上文的初始化主线是一个铺垫，它将框架运行时需要的数据和组件准备完毕，为请求处理主线打下基础。本文基于Struts1.2.8版本，1.3.x系列的差异性将另文说明。
[请求处理接口]
在整体概览和核心组件一文中，我们提到了Struts框架抽象出统一的业务逻辑基类，用户可以继承该类并覆盖请求处理方法，实现自己的业务逻辑。我们再来看一下请求处理方法签名:
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
}与原生的servlet生命周期方法service()相比，该方法增加了三个元素: ActionMapping, ActionForm和ActionForward。由于引入了新的编程元素，使得用户在业务处理上比原生的servlet更加方便。该方法也提现出框架对变化的业务处理逻辑进行抽象，框架的请求处理主线也是围绕该方法展开，包括方法参数的准备和返回值的处理。对变化的进行抽象，对不变的进行固化，这是框架的精髓所在。
[问题]
在分析请求处理主线之前，我们先来思考几个问题。
1. 请求处理过程中哪些东西需要被固化？
2. 如何构建请求处理方法中需要的参数对象(ActionMapping和ActionForm)？
3. 如何对请求处理返回值ActionForward进行处理？
[处理流程]
在整体概览和核心组件一文中，我们介绍了请求处理的核心流程，对各组件功能已经有了整体上的认识。Struts请求处理核心步骤如下：
Struts框架包含默认模块和用户自定义模块，ActionServlet在接收请求后获取当前请求对应的模块信息，进而获取模块对应的请求处理类RequestProcessor，并将请求委托给RequestProcessor处理。整个请求处理过程可以分为两段：一是ActionServlet准备委托处理对象RequestProcessor, 二是RequestProcessor对请求进行处理。下面从源码角度分别解读这两段过程。
[准备委托处理对象]
在Servlet生命周期中，请求处理由生命周期方法service()完成。对于不同的请求method(如Get/Post等)，service()方法内部调用method处理方法(如doGet()/doPost()等)完成请求处理。ActionServlet重写doGet()和doPost()方法，完成对Get和Post请求处理。我们看一下doGet()方法实现:
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
process(request, response);
}该方法比较简单，只是简单调用process()方法，doPost()方法也是如此。我们再看一下process()方法实现：protected void process(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// 1. 获取当前请求对应的Module配置信息(ModuleConfig和MessageResources)，并将信息存入request作用域
ModuleUtils.getInstance().selectModule(request, getServletContext());
// 2. 获取当前请求的ModuleConfig实例
ModuleConfig config = getModuleConfig(request);
// 3. 获取模块对应的处理类RequestProcessor
RequestProcessor processor = getProcessorForModule(config);
if (processor == null) {
processor = getRequestProcessor(config);
}
// 4. 将请求委托给RequestProcessor进行处理
processor.process(request, response);
}以上过程总共分为四步，在代码注释中已经详细说明。这里需要说明一点，每个Module都有唯一的RequestProcessor实例，该实例保存在ServletContext中，使用的key为”Globals.REQUEST_PROCESSOR_KEY + 模块前缀“。如果从ServletContext获取不到该实例，就新建一个实例并保存。因为一个模块只有唯一的RequestProcessor实例，所以RequestProcessor从实现上必须无状态，才不会出现并发问题。
[RequestProcessor请求处理]
上个阶段的目标是获取请求对应的RequestProcessor实例，真正的请求处理过程由RequestProcessor的process()方法完成。该方法实现如下：public void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// 1. 针对multipart请求类型，使用MultipartRequestWrapper对请求进行包装
request = processMultipart(request);
// 2. 获取当前请求的path信息
String path = processPath(request, response);
if (path == null) {
return;
}
// 此处省略log信息
// 3. 从请求中获取locale信息并放入session中
processLocale(request, response);
// 4. 对响应头ContentType和NoCache设置默认值
processContent(request, response);
processNoCache(request, response);
// 5. 增加预处理钩子，可以重写该方法，增加自定义处理逻辑
if (!processPreprocess(request, response)) {
return;
}
// 6. 清除session中的ActionMessages对象，比如错误信息
this.processCachedMessages(request, response);
// 7. 根据path获取当前路径对应的ActionMapping对象
ActionMapping mapping = processMapping(request, response, path);
if (mapping == null) {
return;
}
// 8. 验证用户角色是否在允许列表中
if (!processRoles(request, response, mapping)) {
return;
}
// 9. 获取当前请求对应的ActionForm实例
ActionForm form = processActionForm(request, response, mapping);
// 10. 根据请求参数填充ActionForm实例
processPopulate(request, response, form, mapping);
// 11. 完成Form验证
if (!processValidate(request, response, form, mapping)) {
return;
}
// 12. 完成ActionMapping中forward请求处理
if (!processForward(request, response, mapping)) {
return;
}
// 13. 完成ActionMapping中include请求处理
if (!processInclude(request, response, mapping)) {
return;
}
// 14. 获取当前请求对应的Action实例
Action action = processActionCreate(request, response, mapping);
if (action == null) {
return;
}
// 15. 调用Action实例的execute()方法，完成业务逻辑处理
ActionForward forward =
processActionPerform(request, response,
action, form, mapping);
// 16. 对执行结果ActionForward进行处理
processForwardConfig(request, response, forward);
}该方法条理清晰，可读性高，每一步的作用已经在方法注释中说明。下面对方法中几个核心对象的使用做进一步说明。[ActionMapping]
在第2步中，从request中提取当前请求对应的path信息。该信息将用于第7步中获取path对应的ActionMapping实例。ActionMapping实例是一个请求(路径)对应的框架配置信息载体，通过获取该实例，才能拿到请求对应的ActionForm、Action和ActionForward等配置信息。
[ActionForm]
1. 第9步中，从ActionMapping中获取当前请求的ActionForm名称，然后根据ActionForm名称查找ActionForm配置，进而获取ActionForm实例。 如果没有可重用的ActionForm实例，需要根据ActionForm的类信息通过反射方式生成实例。
2. 第10步中，获取请求的参数列表，然后用这些参数值填充ActionForm中对应的属性值，通过Apache BeanUtils完成填充工作。
3. 第11步中，调用ActionForm的validate()方法完成表单验证。如果验证失败，将错误信息放入request中，结束请求处理。
[Action]
1. 第14步中，从ActionMapping中获取该请求对应的Action名称，RequestProcessor维护了所有Action实例的HashMap，通过Action名称可以获取对应的Action实例。如果没有获取到，则根据Action类信息采用反射方式生成Action实例。由于每个Action对应的实例只有一个，所以Action本身是线程不安全的，编写业务代码时要特别注意。
2. 第15步中，processActionPerform()方法内部调用Action.execute()方法，完成业务逻辑调用。
[ActionForward]
第16步中，对执行结果ActionForward进行处理。processForwardConfig()内部根据配置文件中forward的redirect属性决定采用forward跳转方式还是redirect跳转方式。
[小结]
本文从源码角度分析了Struts1的请求处理主线。ActionServlet在请求处理过程中只负责找到请求对应的RequestProcessor，然后委托给RequestProcessor进行处理；RequestProcessor通过调用ActionMapping/ActionForm/Action/ActionForward这四个核心对象完成请求处理过程。总体上看，请求处理主线逻辑清晰，可读性高。缺陷是可扩展性差，特别是RequestProcessor的处理过程只有一处预处理钩子，不能灵活定制框架处理逻辑。下文将详细分析Struts 1.3.x系列针对请求处理的优化措施。