wildfly，前身是jboss as，從v8開始為差別于jboss eap，更名為wildfly。wildfly 8主要具備如下特性：
java ee7的參考實作（2013年7月止尚未得到java ee7相容認證）
啟動速度更快，占用記憶體更少
子產品化(jsr294)設計
統一配置管理
分布式domain管理
本文主要讨論一下wildfly 8的子產品化系統。
jboss modules就是解決傳統的層級機制的classloader所帶來的jar hell問題：
(1) jar被加載後不使用導緻資源浪費。
(2) 同名jar包的不同版本混在導緻依賴沖突。
jboss modules使所有的jar都打包成為子產品，一個jar再也不會看到依賴中有版本沖突的類，或者加載到一個不需要加載的資源。同時，按需加載子產品可以明顯地提高大型應用的啟動時間。
圖 1 傳統的classloading vs. jboss-modules的classloading
傳統的classloading vs. jboss-modules的classloading
jigsaw已經被延遲到java se 9。jboss modules會與jsr294相容，如果jigsaw項目能夠穩定，并且成為openjdk的一部分，jboss承諾将維護jboss modules的相容性。
個人認為是互補的關系，通過jboss-modules進行子產品化的應用伺服器，使得osgi的bundle形式不再成為子產品化的唯一方式，更加靈活。另外它更為小巧，沒有osgi的sevice層，或者其他osgi提供的更高層次的功能，它隻做一件事情，就是子產品化。
圖 2 wildfly architecture
wildfly architecture
注：上圖中的subsystems沒有列全，full-ha profile的子系統如下圖：
圖 3 full-ha的子系統一覽
full-ha的子系統一覽
接下來簡單與oracle的java ee 7的ri，glassfish v4.0做一個簡單的架構對比
圖 4 glassfish v4.0與wildfly 8的系統棧圖
glassfish v4.0與wildfly 8的系統棧圖
【<b>筆者觀點</b>】glassfish與wildfly在架構實作上最大差別在于子產品系統的構成。
glassfish的做法
采用osgi的子產品化作為glassfish的子產品化系統/基盤；用hk2替代了osgi的服務層。
wildfly的做法
排除廠商利益因素，筆者更喜歡jboss的設計，原因以下：
(1) 通過jboss modules将wildfly與osgi解耦，并且相容jigsaw。設計上更為優雅，且更具遠見。
(2) osgi在java ee開發領域并沒有被廣泛接受(如下圖，來自于zeroturnaround)，離真正落地尚需時日。jboss的設計理念更貼近開發人員。
圖 5 2012年度java标準的被接受度一覽
2012年度java标準的被接受度一覽