Chapter 3. Class Loading and Modules
3.1.1. Overview of Class Loading and Modules
3.1.2. Class Loading
- Static Modules
- Static Modules are predefined in the
EAP_HOME/modules/directory of the application server. Each sub-directory represents one module and defines a
main/subdirectory that contains a configuration file (
module.xml) and any required JAR files. The name of the module is defined in the
module.xmlfile. All the application server provided APIs are provided as static modules, including the Java EE APIs as well as other APIs such as JBoss Logging.
Example 3.1. Example module.xml file
<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.1.15.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>The module name,
com.mysql, should match the directory structure for the module, excluding the
main/subdirectory name.The modules provided in JBoss EAP distributions are located in a
systemdirectory within the
EAP_HOME/modulesdirectory. This keeps them separate from any modules provided by third parties.Any Red Hat provided layered products that layer on top of JBoss EAP 6.1 or later will also install their modules within the
systemdirectory.Creating custom static modules can be useful if many applications are deployed on the same server that use the same third-party libraries. Instead of bundling those libraries with each application, a module containing these libraries can be created and installed by the JBoss administrator. The applications can then declare an explicit dependency on the custom static modules.Users must ensure that custom modules are installed into the
EAP_HOME/modulesdirectory, using a one directory per module layout. This ensures that custom versions of modules that already exist in the
systemdirectory are loaded instead of the shipped versions. In this way, user provided modules will take precedence over system modules.If you use the
JBOSS_MODULEPATHenvironment variable to change the locations in which JBoss EAP searches for modules, then the product will look for a
systemsubdirectory structure within one of the locations specified. A
systemstructure must exist somewhere in the locations specified with
- Dynamic Modules
- Dynamic Modules are created and loaded by the application server for each JAR or WAR deployment (or subdeployment in an EAR). The name of a dynamic module is derived from the name of the deployed archive. Because deployments are loaded as modules, they can configure dependencies and be used as dependencies by other deployments.
3.1.4. Module Dependencies
Explicit dependencies are declared by the developer in the configuration file. Static modules can declare dependencies in the
module.xml file. Dynamic modules can have dependencies declared in the
jboss-deployment-structure.xml deployment descriptors of the deployment.
Implicit dependencies are added automatically by the application server when certain conditions or meta-data are found in a deployment. The Java EE 6 APIs supplied with JBoss EAP 6 are examples of modules that are added by detection of implicit dependencies in deployments.
jboss-deployment-structure.xmldeployment descriptor file. This is commonly done when an application bundles a specific version of a library that the application server will attempt to add as an implicit dependency.
Example 3.2. Module dependencies
- Module A declares an explicit dependency on Module C, or
- Module B exports its dependency on Module C.
3.1.5. Class Loading in Deployments
- WAR Deployment
- A WAR deployment is considered to be a single module. Classes in the
WEB-INF/libdirectory are treated the same as classes in
WEB-INF/classesdirectory. All classes packaged in the WAR will be loaded with the same class loader.
- EAR Deployment
- EAR deployments are made up of more than one module. The definition of these modules follows these rules:
Subdeployment modules (the WAR and JAR deployments within the EAR) have an automatic dependency on the parent module. However they do not have automatic dependencies on each other. This is called subdeployment isolation and can be disabled on a per deployment basis or for the entire application server.Explicit dependencies between subdeployment modules can be added by the same means as any other module.
lib/directory of the EAR is a single module called the parent module.
- Each WAR deployment within the EAR is a single module.
- Each EJB JAR deployment within the EAR is a single module.
3.1.6. Class Loading Precedence
- Implicit dependencies.These are the dependencies that are added automatically by JBoss EAP 6, such as the JAVA EE APIs. These dependencies have the highest class loader precedence because they contain common functionality and APIs that are supplied by JBoss EAP 6.Refer to Section 3.9.1, “Implicit Module Dependencies” for complete details about each implicit dependency.
- Explicit dependencies.These are dependencies that are manually added in the application configuration. This can be done using the application's
MANIFEST.MFfile or the new optional JBoss deployment descriptor
jboss-deployment-structure.xmlfile.Refer to Section 3.2, “Add an Explicit Module Dependency to a Deployment” to learn how to add explicit dependencies.
- Local resources.Class files packaged up inside the deployment itself, e.g. from the
WEB-INF/libdirectories of a WAR file.
- Inter-deployment dependencies.These are dependencies on other deployments in a EAR deployment. This can include classes in the
libdirectory of the EAR or classes defined in other EJB jars.
3.1.7. Dynamic Module Naming
- Deployments of WAR and JAR files are named with the following format:
store.jarwill have the module names of
- Subdeployments within an Enterprise Archive are named with the following format:
deployment.EAR_NAME.SUBDEPLOYMENT_NAMEFor example, the subdeployment of
reports.warwithin the enterprise archive
accounts.earwill have the module name of
jboss-deployment-structure.xmlis a new optional deployment descriptor for JBoss EAP 6. This deployment descriptor provides control over class loading in the deployment.