struts1源码阅读（3）

    前一章写struts配置文件的解析感觉有点太细了，且由于笔头功夫稍欠火候，感觉写得不够彻底。这章从宏观上对解析做个总结，希望能够先从整体上熟悉它。

    之前也提到，ActionServlet在解析配置文件时是按照模块来进行的，对每个模块都会有一个ModuleConfig对象。这个对象是非常重要的，struts中的配置信息都可以从中获得，而且在之后处理用户请求时有很大的用武之地。ModuleConfig其实是一个接口，在Struts1中有一个默认的实现类ModuleConfigImpl。当然，我们在配置servlet时，可以通过指定初始化参数configFactory，提供一个自定义的ModuleConfigFactory来生成ModuleConfig对象。如果没有指定初始化参数，则默认使用ModuleConfigImpl。

    该接口的类图（列出了主要的几个方法）如下：

    在对struts配置文件解析的过程中，每次对一个标签解析完毕后，则会把对应的Config对象加入到ModuleConfig对象中，具体调用的就是这些方法。这些操作也都是在SetNextRule对象中完成的。查看SetNextRule的源码就可以知道，该类的实际操作都是在end()方法里完成的，也就是说，在对某个标签解析结束时，才会调用。

    当然，对于一个标签可能会配置多个，比如<action>。对于配置文件中的每个<action>，实际上都有一个AcionConfig对象与之对应，然后通过调用addActionConfig()，将该对象放在ModuleConfig对象的一个Map里。该Map会以Action的path为key，以ActionConfig对象作为值。

    上面说的是将这些config对象添加到ModuleConfig对象中，至于这些config对象是如何生成，以及config对象的属性是如何设置的，实际上都是Digester的功劳了，上一章比较详细的说过了。这里再从处理的流程上提一下，以便有个宏观印象。

    Digester在解析标签时，有两个方法不得不提：

    1、startElement：解析标签开始时的处理；

    2、endElement：解析标签结束时的处理。

    实际上这两个方法在处理时，都是调用与当前标签相对应的Rule对象进行处理。第二章中有提到将元素与规则进行映射，实际上就是这里用到了。Rule类图如下：

    在startElement()方法中，会调用Rule的begin()方法。在endElement()方法中会调用Rule的body()和end()方法。Rule的子类会选择性的重写这三个方法，Rule类中这三个方法都是空的，也就是不做任何处理。

    以FactoryCreateRule类为例（<action>标签会用到），begin()方法根据工厂对象创建一个对象（<action>标签对应的工厂类为ActionMappingFactory），并将这个对象放入Digester对象的栈中。end()方法将创建的对象从栈中弹出。

    希望这次写得明白些。。。