Discover JBoss AS 7 modularity

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

This tutorial provides a low-level view of JBoss AS 7 class loading mechanism which is based on the JBoss Modules project.

 The Java Classloader is a part of the Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine. However there are some various ways in which the classloading process can end up not working, we can enumerate:

- A developer or deployer of a Java application has accidentally made two different versions of a library available to the system. This will not be considered an error by the system. Rather, the system will load classes from one or the other library. Adding the new library to the list of available libraries instead of replacing it, may see the application still behaving as though the old library is in use, which it may well be.

- Two libraries (or a library and the application) require different versions of the same third library. If both versions of the third library use the same class names, there is no way to load both versions of the third library with the same classloader.

- The most complex JAR hell problems arise in circumstances that take advantage of the full complexity of the classloading system. A Java program is not required to use only a single “flat” classloader, but instead may be composed of several (potentially very many) nested, cooperating classloaders. Classes loaded by different classloaders may interact in complex ways not fully comprehended by a developer, leading to inexplicable errors or bugs.

Class loading is considerably different to previous versions of JBoss AS. Class loading is based on the JBoss Modules project. Instead of the more familiar hierarchical class loading environment, AS7′s class loading is based on modules that have to define explicit dependencies on other modules. Deployments in AS7 are also modules, and do not have access to classes that are defined in jars in the application server unless an explicit dependency on those classes is defined.

How it works?

To understand how it works internally we use JArchitect and CQLinq queries to query the JBoss-modules code base. CQlinq is a powerful query language based on linq to query the code base, you can try its possibilities from “Queries and Rules Edit” view.

jboss module

To start let’s search what happens when the main method is invoked by executing the following CQLinq query:

from m in Methods where m.IsUsedBy (“org.jboss.modules.Main.main(String[])”)
select new { m, m.NbBCInstructions }

jboss module 

The java.lang.Thread.setContextClassLoader() method is invoked to set the context ClassLoader. The context ClassLoader can be set when a thread is created, and allows the creator of the thread to provide the appropriate class loader to code running in the thread when loading classes and resources.

Let’s discover the class loaders defined by JBoss:

from t in Types where !t.IsThirdParty
let depth0 = t.DepthOfDeriveFrom(“java.lang.ClassLoader”)
where depth0 >= 0 orderby depth0
select new { t, depth0,IsAbstract=t.IsAbstract }

jboss module


There are two classes inheriting from ClassLoader but only ModuleClassLoader could be instantiated. ModuleClassLoader inherits from ConcurrentClassLoader which inherit from SecureClassLoader from the jdk. ConcurrentClassLoader is useful to treat dead lock problems. Here is where the ClassModuleLoader is instantiated:

from m in Methods
let depth0 = m.DepthOfCreateA(“org.jboss.modules.ModuleClassLoader”)
where depth0 == 1
select new { m, depth0 }

jboss module 


What’s interesting is that each module has its own class loader, different version of the same jar could be loaded for different modules loaded.

What’s exactly a module?

To understand what the module is, let’s discover how a module is described, and here’s an example of a module descriptor:

<module xmlns=”urn:jboss:module:1.1″ name=”org.jboss.msc”>

<main-class name=”org.jboss.msc.Version”/>

   <property name=”” value=”foo”/>

     <resource-root path=”jboss-msc-1.0.1.GA.jar”/>

       <module name=”javax.api”/>
       <module name=”org.jboss.logging”/>
       <module name=”org.jboss.example”>
                       <path name=”org.jboss.example.tests”/>


         <!– Optional deps –>
         <module name=”javax.inject.api” optional=”true”/>
         <module name=”org.jboss.threads” optional=”true”/>
         <module name=”org.jboss.vfs” optional=”true”/>


A module descriptor is an XML file which describes the structure, content, dependencies, filtering, and other attributes of a module. ConcreteModuleSpec is the class from JBoss containing these infos. And here’s the dependency graph showing all classes used by it.

jboss module 



A resource is described by the ResourceLoaderSpec, a dependency by DependencySpec and the properties by a Map.  Let’s describe each section of the module descriptor.


Related articles available on

JBoss AS 7 introduction

This is an introduction tutorial to the newest JBoss AS 7 which a

Develop Java EE applications with JBoss AS 7

In this tutorial we will learn how to create and deploy a Java EE

Adding users with JBoss AS 7

If you are planning to add new users to your management interface

Using JBoss AS 7 management API programmatically

In this tutorial we will show how to use detyped management API t

JNDI view in JBoss AS 7

JNDI can be checked on the naming subsystem of the application se

How to install a module on WildFly / JBoss AS 7

Installing a module on WildFly / JBoss AS 7 requires creating a p