A Module is a logical grouping of classes used for class loading and dependency management. JBoss EAP 6 identifies two different types of modules, sometimes called static and dynamic modules. However the only difference between the two is how they are packaged. All modules provide the same features.
- 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.xml file. 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 7.1. Example module.xml file
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
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
system directory within the
JBOSS_HOME/modules directory. 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
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
JBOSS_HOME/modules directory, using a one directory per module layout. This ensures that custom versions of modules that already exist in the
system directory are loaded instead of the shipped versions. In this way, user provided modules will take precedence over system modules.
If you use the
JBOSS_MODULEPATH environment variable to change the locations in which JBoss EAP searches for modules, then the product will look for a
system subdirectory structure within one of the locations specified. A
system structure 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.
Modules are only loaded when required. This usually only occurs when an application is deployed that has explicit or implicit dependencies.
7.1.3. Module Dependencies
A module dependency is a declaration that one module requires the classes of another module in order to function. Modules can declare dependencies on any number of other modules. When the application server loads a module, the modular class loader parses the dependencies of that module and adds the classes from each dependency to its class path. If a specified dependency cannot be found, the module will fail to load.
Deployed applications (JAR and WAR) are loaded as dynamic modules and make use of dependencies to access the APIs provided by JBoss EAP 6.
There are two types of dependencies: explicit and implicit.
Explicit dependencies are declared in configuration by the developer. Static modules can declare dependencies in the modules.xml file. Dynamic modules can have dependencies declared in the MANIFEST.MF or jboss-deployment-structure.xml deployment descriptors of the deployment.
Explicit dependencies can be specified as optional. Failure to load an optional dependency will not cause a module to fail to load. However if the dependency becomes available later it will NOT be added to the module's class path. Dependencies must be available when the module is loaded.
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.
Deployments can also be configured to exclude specific implicit dependencies. This is done with the jboss-deployment-structure.xml deployment 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.
A module's class path contains only its own classes and that of it's immediate dependencies. A module is not able to access the classes of the dependencies of one of its dependencies. However a module can specify that an explicit dependency is exported. An exported dependency is provided to any module that depends on the module that exports it.
Example 7.2. Module dependencies
Module A depends on Module B and Module B depends on Module C. Module A can access the classes of Module B, and Module B can access the classes of Module C. Module A cannot access the classes of Module C unless:
Module A declares an explicit dependency on Module C, or
Module B exports its dependency on Module C.
7.1.4. Subdeployment Class Loader Isolation
Each subdeployment in an Enterprise Archive (EAR) is a dynamic module with its own class loader. By default a subdeployment can access the resources of other subdeployments.
If a subdeployment should not access the resources of other subdeployments (strict subdeployment isolation is required) then this can be enabled.