struts1源码分析(三)请求处理主线

在初始化主线一文中，我们详细分析了框架的初始化过程。本文将从Struts的另外一条主线出发，分析框架的实现原理。上文的初始化主线是一个铺垫，它将框架运行时需要的数据和组件准备完毕，为请求处理主线打下基础。本文基于Struts1.2.8版本，1.3.x系列的差异性将另文说明。

 

[请求处理接口]

在整体概览和核心组件一文中，我们提到了Struts框架抽象出统一的业务逻辑基类，用户可以继承该类并覆盖请求处理方法，实现自己的业务逻辑。我们再来看一下请求处理方法签名:

Java代码  

1. public ActionForward execute(  
2.     ActionMapping mapping,  
3.     ActionForm form,  
4.     HttpServletRequest request,  
5.     HttpServletResponse response)  
6.     throws Exception {  
7. }  

与原生的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()方法实现:

 

Java代码  

1. public void doGet(HttpServletRequest request,  
2.           HttpServletResponse response)  
3.     throws IOException, ServletException {  
4.   
5.     process(request, response);  
6.   
7. }  

该方法比较简单，只是简单调用process()方法，doPost()方法也是如此。我们再看一下process()方法实现：

 

 

Java代码  

1. protected void process(HttpServletRequest request, HttpServletResponse response)  
2.     throws IOException, ServletException {  
3.   
4.     // 1. 获取当前请求对应的Module配置信息(ModuleConfig和MessageResources)，并将信息存入request作用域  
5.     ModuleUtils.getInstance().selectModule(request, getServletContext());  
6.       
7.     // 2. 获取当前请求的ModuleConfig实例  
8.     ModuleConfig config = getModuleConfig(request);  
9.   
10.     // 3. 获取模块对应的处理类RequestProcessor  
11.     RequestProcessor processor = getProcessorForModule(config);  
12.     if (processor == null) {  
13.        processor = getRequestProcessor(config);  
14.     }  
15.       
16.     // 4. 将请求委托给RequestProcessor进行处理  
17.     processor.process(request, response);  
18.   
19. }  

以上过程总共分为四步，在代码注释中已经详细说明。这里需要说明一点，每个Module都有唯一的RequestProcessor实例，该实例保存在ServletContext中，使用的key为”Globals.REQUEST_PROCESSOR_KEY + 模块前缀“。如果从ServletContext获取不到该实例，就新建一个实例并保存。因为一个模块只有唯一的RequestProcessor实例，所以RequestProcessor从实现上必须无状态，才不会出现并发问题。

 

[RequestProcessor请求处理]

上个阶段的目标是获取请求对应的RequestProcessor实例，真正的请求处理过程由RequestProcessor的process()方法完成。该方法实现如下：

 

Java代码  

1. public void process(HttpServletRequest request,  
2.                     HttpServletResponse response)  
3.     throws IOException, ServletException {  
4.   
5.     // 1. 针对multipart请求类型，使用MultipartRequestWrapper对请求进行包装  
6.     request = processMultipart(request);  
7.   
8.     // 2. 获取当前请求的path信息  
9.     String path = processPath(request, response);  
10.     if (path == null) {  
11.         return;  
12.     }  
13.       
14.     // 此处省略log信息  
15.   
16.     // 3. 从请求中获取locale信息并放入session中  
17.     processLocale(request, response);  
18.   
19.     // 4. 对响应头ContentType和NoCache设置默认值  
20.     processContent(request, response);  
21.     processNoCache(request, response);  
22.   
23.     // 5. 增加预处理钩子，可以重写该方法，增加自定义处理逻辑  
24.     if (!processPreprocess(request, response)) {  
25.         return;  
26.     }  
27.       
28.     // 6. 清除session中的ActionMessages对象，比如错误信息  
29.     this.processCachedMessages(request, response);  
30.   
31.     // 7. 根据path获取当前路径对应的ActionMapping对象  
32.     ActionMapping mapping = processMapping(request, response, path);  
33.     if (mapping == null) {  
34.         return;  
35.     }  
36.   
37.     // 8. 验证用户角色是否在允许列表中  
38.     if (!processRoles(request, response, mapping)) {  
39.         return;  
40.     }  
41.   
42.     // 9. 获取当前请求对应的ActionForm实例  
43.     ActionForm form = processActionForm(request, response, mapping);  
44.     // 10. 根据请求参数填充ActionForm实例  
45.     processPopulate(request, response, form, mapping);  
46.     // 11. 完成Form验证  
47.     if (!processValidate(request, response, form, mapping)) {  
48.         return;  
49.     }  
50.   
51.     // 12. 完成ActionMapping中forward请求处理  
52.     if (!processForward(request, response, mapping)) {  
53.         return;  
54.     }  
55.       
56.     // 13. 完成ActionMapping中include请求处理  
57.     if (!processInclude(request, response, mapping)) {  
58.         return;  
59.     }  
60.   
61.     // 14. 获取当前请求对应的Action实例  
62.     Action action = processActionCreate(request, response, mapping);  
63.     if (action == null) {  
64.         return;  
65.     }  
66.   
67.     // 15. 调用Action实例的execute()方法，完成业务逻辑处理  
68.     ActionForward forward =  
69.         processActionPerform(request, response,  
70.                              action, form, mapping);  
71.   
72.     // 16. 对执行结果ActionForward进行处理  
73.     processForwardConfig(request, response, forward);  
74.   
75. }  

该方法条理清晰，可读性高，每一步的作用已经在方法注释中说明。下面对方法中几个核心对象的使用做进一步说明。

 

[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系列针对请求处理的优化措施。

 

转载: http://learnworld.iteye.com/blog/1998021