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标准的被接受度一览