個人了解 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