<b>阅读目录</b>
<a href="http://www.cnblogs.com/java-class/p/5113897.html#_label0">1. configuration</a>
<a href="http://www.cnblogs.com/java-class/p/5113897.html#_label1">2. defaultconfiguration</a>
<a href="http://www.cnblogs.com/java-class/p/5113897.html#_label2">3. delegatingconfiguration</a>
<a href="http://www.cnblogs.com/java-class/p/5113897.html#_label3">4. webwork[三][四]小结</a>
webwork做为经典的web mvc 框架，个人觉得源码中配置文件这部分代码的实现十分考究。
支持自定义自己的配置文件、自定义配置文件读取类、自定义国际化支持。
可以作为参考，单独引入到其他项目中，下面是configuration相关类的继承关系：
configuration 作为 webwork 配置文件的核心类，起到了配置信息读取的门户，默认实现类中间引入了代理类 delegatingconfiguration 与底层的具体实现读取的 propertiesconfiguration 完全解耦。在项目中使用时，只需要引入 configuration 类,如下代码即可获取配置信息；
getstring 方法会调用 configuration 自身的get 方法，get 方法中调用 getconfiguration 方法：
configuration 中定义的两个静态变量defaultimpl 和configurationimpl，还有 一个setconfiguration方法用来设置configurationimpl;
defaultimpl 是 webwork 的默认实现类实例的引用，在每一次读取配置文件时，都会去判断是否在 webwork.properties 是否配置了 webwork.configuration 参数(其实框架是无法实现热读配置文件的，下面会说到，每次判断只是确定读取配置信息，使用的框架默认类还是用户自定义类);
如果设置了在调用 getdefaultconfiguration() 获得自定义读取类引用 configurationimpl,否则返回 webwork 自己的 configuration 实现。
(这里要说一下，随意变动上线系统的配置文件，你会悲剧的，修改前记得问清楚)
第一次调用 getdefaultconfiguration() 方法时，默认实现 defaultimpl 是空，则进入创建一 个 webwork 自己的实现 defaultconfiguration 的实例，并通过这个实例读取 webwork 配置信息。
上面代码第5行有个特殊的地方，和下面的 delegatingconfiguration中的很相似,下面一起说。
defaultconfiguration 并没有直接取读取properties文件，而是通过 propertiesconfiguration 来实现properties文件的读取；
propertiesconfiguration 也同样是 configuration 的子类，通过java.util.properties 来解析properties文件，并 赋予自身properties 实例settings，并覆盖了父类的setimpl、getimpl、issetimpl、 listimpl 四个方法；
defaultconfiguration 通 过 propertiesconfiguration 首 先 加 载 的 是 webwork.properties，之后又加载了default.properties；
（这里需要说一下，default.properties 是webwork 框架自身的配置文件，封装在 jar 中，假如你在项目的 web.properties 中定义了与 default.properties 相同的参数，看上面程序配置文件的加载顺序，框架先加载你的配置文件，然后加载默认配置文件，你会发现你的参数是不会起作用的,如果你想让你的参数覆盖框架中的，这里你需要自定义配置文件，并且在 项目 webwork.properties 中配置webwork.custom.properties 参数）
将 propertiesconfiguration 实例放入list中，然后创建一个和 list一样大的configuration[]数组，并把list 转型为 configuration[]赋予 实例化 delegatingconfiguration；
加载完两个properties 文件，并创建了delegatingconfiguration 实例之后， defaultconfiguration开始在这两个属性文件中查找 webwork.custom.properties，文件名之间用“,”隔开。找到配置后，分割文件名并分别创建propertiesconfiguration 实例，加入list，加载完所有配置文 件后重新创建delegatingconfiguration 实例。
加载完所有的webwork 属性文件后， 查找属性文件中指定的国际化资源文件（文件名同样用“,”隔开），如果有，则加载到 localizedtextutil 中，供以后使用。
(毕竟是好多年前编写的源码，这里面的 stringtokenizer 出于兼容性的原因已经被遗留（虽然在新代码中并不鼓励使用它）。api 中建议所有寻求此功能的人使用 string 的 split 方法或 java.util.regex 包)
delegatingconfiguration 也同样是 configuration 的子类，内部保存了一个 configuration[]数组configlist，并覆 盖了父类的setimpl、getimpl、issetimpl、listimpl 四个方法，实现对configlist 的操作；
如果用户没有指定自己的 configuration 实现，则 configuration.getstring 最终调用的是 delegatingconfiguration 的 getimpl；
在 delegatingconfiguration 的setimpl 方法实现中，有一个特别的地方，其实也就是上面 configuration提到的f，底层的实现：
webwork不支持动态的增加属性配置，但允许修改已配置的属性， configlist[i].getimpl(name); 调用的是 propertiesconfiguration 的 getimpl 方法，实现如下：
propertiesconfiguration 会在settings 里去找name，如果找到就返回配置信息，在 delegatingconfiguration 的setimpl 方法中通过configlist[i].setimpl(name, value)修改该属性的配置，否则抛illegalargumentexception 异常，该异常在 delegatingconfiguration 的 getimpl 方法中截 获 ,继续往被调用函数抛。 此时则不会执行 configlist[i].setimpl(name, value);从而保证了只有配置过了的属性可以被修改，在服务运行的过程中不会有新增的属性，所有的属性都由 web 服务第一次启动的时候加载。
以上分析我们可以看见，web 服务启动的时候，servletdispatcher 通过 defaultconfiguration 先 加 载 webwork.properties 和 default.properties ， 并 查 找 webwork.properties中webwork.custom.properties 配置的其他属性文件加载。加载完毕 后再通过属性中配置的 webwork.custom.i18n.resources 加载国际化资源文件供以后 使用。之后再查找 webwork.configuration 属性看是否用户指定了自己的 configuration 实现，如果有就用用户自己的configuration 实现，否则返回webwork 自己的实现（delegatingconfiguration）。大部分情况下，使用 webwork 自己的实现 已经足够，用户不需要自己去实现一个 configuration，除非你想加载xml等格式的配 置文件。
如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】
如果，您希望更容易地发现我的新博客，不妨点击一下左下角的【关注我】
如果，您对我的博客内容感兴趣，请继续关注我的后续博客，我是【orson】
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段 声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
转载：http://www.cnblogs.com/java-class/p/5113897.html