个人理解 webwork 与 struts2 都是将xml配置文件作为 controler 跳转的基本依据，webwork 跳转 action 前 xml 文件的读取依赖 xwork-1.0.jar,底层由 xwork实现，这部门代码读起来不是很轻松，在此做下记录供后续查阅和项目借鉴。今天的代码分析对应 下图 webwork 框架流转图中红框框的地方。
webwork xml配置文件读取的入口、后续的所有处理都是 action 调用类 defaultactionproxy 这句代码:
configurationmanager 做为整个 xwork 获取配置信息的管理者，掌控 configuration 与 xmlconfigurationprovider 两大类的实例化时机；
configurationmanager的 getconfiguration()方法实现如下：
注意框架中的这个方法前面的修饰符是 synchronized 并发线程不能同时访问该函数；
可以通过 setconfiguration方法设置一个 configurationinstance，如果没有设置，返回xwork的默认实现类， defaultconfiguration;
defaultconfiguration 实现接口 configuration ，其中含有内部类 runtimeconfigurationimpl 实现了 runtimeconfiguration 接口;
入口中defaultactionproxy的构造函数中调用的：configurationmanager.getconfiguration().getruntimeconfiguration().getactionconfig 默认的实现为 runtimeconfigurationimpl ;
configurationmanager 在实例化 defaultconfiguration 对象后，紧接着调用了该对象的 reload();
reload() 通过遍历 configurationmanager 中的configurationproviders链表，来逐个初始化 xwork 的配置信息。默认只有一个 configurationprovider，也就是 xmlconfigurationprovider，同样只会读取一个xwork的配置信息，就是xwork.xml;
这里要注意一下，大项目都是许多工程师并发编写，一个xwork.xml 配置文件显示是不能满足各个模块一起开发的要求，这里需要编写一个类去继承 xmlconfigurationprovider，这个类需要将项目中分散在各个模块下的 xwork.xml 配置文件整合起来，写入到加载到 configurationproviders 链表当中(实现方式多种多样，看项目具体情况)；
configurationmanager的 getconfigurationproviders方法实现如下：
在没继承 xmlconfigurationprovider 情况下，reload 函数里的 for 循环只会执行一次，调用xmlconfigurationprovider的 init方法;
调用该方法时， defaultconfiguration把自身作为参数传了进去。 之后 xmlconfigurationprovider 的 init 方法会通过自身的loadconfigurationfile方法回调defaultconfiguration的addpackageconfig方法将解析出的 action 配置信息存放回 defaultconfiguration 的map 类型成员变量 packagecontexts 中，供其内部类 runtimeconfigurationimpl 的方法getactionconfig 返回某一个 action 配置信息时查找使用;
getactionconfig 返回的 actionconfig 是 xwork 的一个类，包含了某一个 action 的所有配置信息以及执行后的所有可能结果等;
xmlconfigurationprovider 的 init 方法会通过自身的 loadconfigurationfile 方法首先读取xwork.xml配置信息，然后通过发现include标签找到其他配置文件去读取;
该机制保证了用户可以将一个庞大的xwork配置文件拆分为多个，在 xwork.xml通过 include标签引用进来，但要注意同名的 action的覆盖问题[和上面说的注意区别]。
loadconfigurationfile 通过递归解析完所有的配置文件，并将他们放入defaultconfiguration的map类型成员变量packagecontexts中。
具体代码如下：
xmlconfigurationprovider 和 defaultconfiguration 分别实现 configurationprovider与 configuration 接口，可以仔细看下接口中定义的抽象方法，十分合理，为程序的可扩展性提供了基础，做到了“对修改封闭，对扩展开放”。
configurationmanager 采用了工厂模式来作为一个统一的入口 ，掌握了 defaultconfiguration 与 configurationprovider 的实例化时机，实例化采用单例模式，让两类的实例化对象有且只有一个，即解耦两类的同时保证了程序的高内聚，十分考究。
defaultconfiguration 的内部类的使用让程序的设计眼前一类，在看到它之后我一直在思考，为什么不将 内部类 runtimeconfigurationimpl 单独作为一个类交由 configurationmanager 统一管理？
runtimeconfigurationimpl 如果交由configurationmanager 统一管理非常的不合理，runtimeconfigurationimpl 中的唯一属性 namespaceactionconfigs 由外部类初始化填入， configurationmanager 到 赋值 namespaceactionconfigs 属性的过程：
内部类 runtimeconfigurationimpl 可以随意使用外部类的成员变量（包括私有）而不用生成外部类的对象，隐藏你不想让别人知道的操作,使整个程序编码更加简洁。
这几个类中 方法前的修饰符，用的十分合理，包括private,protected。对多线程访问的合理控制。
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】
如果，您希望更容易地发现我的新博客，不妨点击一下左下角的【关注我】
如果，您对我的博客内容感兴趣，请继续关注我的后续博客，我是【orson】
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段 声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转自：http://www.cnblogs.com/java-class/p/5125183.html