Using JBoss Modules in JBoss EAP 5?

Resolution

JBoss Modules is designed to solve a single problem which is to solve the classpath / dependency issues.  OSGI does more than that is is more complicated.  So JBoss Modules is a non spec sub project for JBoss AS 7 / EAP 6 in which the goal is to only expose the J2EE API classes and not any of the third party implementations that JBoss uses internally.  The goal is to fix issues that customers have when they want to package a different version of one of these third party libraries or frameworks in their application and have classloading issues because JBoss EAP 4.x and 5.x have a hierarchical classloader and even though you can isolate your applications from each other.  The parent classloader of the application is the UnifiedClassloader which has the classes of what JBoss uses internally in it, which may cause issues in some cases.

One of the main advantages of using JBoss Modules is the low consumption of Memory. With JBoss Modules, it is possible to share libraries among the applications in order to not duplicate these libraries in each application. Consequently, the deployment size decrease when you have JBoss Modules Also, the PermGen size of the JVM will decrease, so if you are deploying the same application many times it won't throw an OutOfMemoryError: PermGen size.

On the other hand, module configuration is JBoss specific and not part of the Java EE specification. Custom JBoss Modules require the libraries be put in the $JBOSS_HOME/modules directory and a module.xml created to list the libraries in the module as well as any other modules it depends on.