Skip to end of metadata
Go to start of metadata

As explained in the ClassLoading in AS7 article, JBoss AS7 is based on module classloading. A class within a module B isn't visible to a class within a module A, unless module B adds a dependency on module A. Module dependencies can be explicitly (as explained in that classloading article) or can be "implicit". This article will explain what implicit module dependencies mean and how, when and which modules are added as implicit dependencies.

What's an implicit module dependency?

Consider an application deployment which contains EJBs. EJBs typically need access to classes from the javax.ejb.* package and other Java EE API packages. The jars containing these packages are already shipped in JBoss AS and are available as "modules". The module which contains the javax.ejb.* classes has a specific name and so does the module which contains all the Java EE API classes. For an application to be able to use these classes, it has to add a dependency on the relevant modules. Forcing the application developers to add module dependencies like these (i.e. dependencies which can be "inferred") isn't a productive approach. Hence, whenever an application is being deployed, the deployers within the server, which are processing this deployment "implicitly" add these module dependencies to the deployment so that these classes are visible to the deployment at runtime. This way the application developer doesn't have to worry about adding them explicitly. How and when these implicit dependencies are added is explained in the next section.

How and when is an implicit module dependency added?

When a deployment is being processed by the server, it goes through a chain of "deployment processors". Each of these processors will have a way to check if the deployment meets a certain criteria and if it does, the deployment processor adds a implicit module dependency to that deployment. Let's take an example - Consider (again) an EJB3 deployment which has the following class:

As can be seen, we have a simple @Stateless EJB. When the deployment containing this class is being processed, the EJB deployment processor will see that the deployment contains a class with the @Stateless annotation and thus identifies this as a EJB deployment. This is just one of the several ways, various deployment processors can identify a deployment of some specific type. The EJB deployment processor will then add an implicit dependency on the Java EE API module, so that all the Java EE API classes are visible to the deployment.

Some subsystems will always add a API classes, even if the trigger condition is not met. These are listed separately below. 

In the next section, we'll list down the implicit module dependencies that are added to a deployment, by various deployers within JBoss AS.

Which are the implicit module dependencies?

Subsystem responsible for adding the implicit dependency
Dependencies that are always added Dependencies that are added if a trigger condition is met

Trigger which leads to the implicit module dependency being added
Core Server
  • javax.api 
  • sun.jdk
  • org.jboss.logging
  • org.apache.log4j
  • org.apache.commons.logging
  • org.slf4j
  • org.jboss.logging.jul-to-slf4j-stub
EE Subsystem
  • javaee.api
EJB3 subsystem
  • javaee.api
The presence of ejb-jar.xml (in valid locations in the deployment, as specified by spec) or the presence of annotation based EJBs (ex: @Stateless, @Stateful, @MessageDriven etc)
JAX-RS (Resteasy) subsystem
  • javax.xml.bind.api
  • org.jboss.resteasy.resteasy-atom-provider 
  • org.jboss.resteasy.resteasy-cdi 
  • org.jboss.resteasy.resteasy-jaxrs 
  • org.jboss.resteasy.resteasy-jaxb-provider 
  • org.jboss.resteasy.resteasy-jackson-provider 
  • org.jboss.resteasy.resteasy-jsapi 
  • org.jboss.resteasy.resteasy-multipart-provider 
  • org.jboss.resteasy.async-http-servlet-30
The presence of JAX-RS annotations in the deployment
JCA sub-system
  • javax.resource.api
  • javax.jms.api 
  • javax.validation.api 
  • org.jboss.logging 
  • org.jboss.ironjacamar.api 
  • org.jboss.ironjacamar.impl 
  • org.hibernate.validator
If the deployment is a resource adaptor (RAR) deployment.
JPA (Hibernate) subsystem
  • javax.persistence.api
  • javaee.api
  • org.hibernate
  • org.javassist
  • org.eclipse.persistence
  • org.apache.openjpa
The presence of an @PersistenceUnit or @PersistenceContext annotation, or a <persistence-unit-ref> or <persistence-context-ref> in a deployment descriptor.

. JBoss AS 7 maps persistence provider names to module names, so if you name a specific provider in persistence.xml it'll add a dependency on the appropriate module. If this is undesired, exclude it using a jboss-deployment-structure.xml file.
SAR Subsystem  
  • org.jboss.logging
  • org.jboss.modules
The deployment is a SAR archive
Security Subsystem
  • org.picketbox
Web Subsystem  
  • javaee.api
  • com.sun.jsf-impl
  • org.hibernate.validator
  • org.jboss.logging
The deployment is a WAR archive. JSF is only added if used. Multiple version options exist for mojarra.
Web Services Subsystem
Weld (CDI) Subsystem  
  • javax.persistence.api
  • javaee.api
  • org.javassist
  • org.jboss.interceptor
  • org.jboss.logging
  • org.jboss.weld.core
  • org.jboss.weld.api
  • org.jboss.weld.spi
If a beans.xml file is detected in the deployment
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 24, 2012

    Information on where to find the full list of mappings from persistence provider name in persistence.xml to JBoss module name would be helpful. Right now I can't find any public listing.

    It's in jpa/core/src/main/java/org/jboss/as/jpa/config/ in the JBoss AS 7 sources in case anyone's going to go source-diving for it; see eg Configuration.PROVIDER_MODULE_ECLIPSELINK .

    You can look up a particular mapping using Configuration.getProviderModuleNameFromProviderClassName(String providerClassName) but can't list all mappings via any public interface.

    You can reflectively access the Map<String, String> Configuration.providerClassToModuleName member if you need to list 'em all, but of course that's access to private API and could break at any time.

    If you want to exclude an automatic mapping using jboss-deployment-structure.xml, there might be an issue there. See