• Jboss Global Module Sloth
• Jboss Global Module Slot Tool
• Jboss Global Module Slots
• Jboss Global Module Slot Reset

Migrating from https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBossModules

• 6JEE Deployment Modules
  • 6.3EAR Deployments
• 7Inter-Module Dependencies

May 18, 2017 but the module name remains with war filename (my-project-1.0.0-SNAPSHOT.war).Actually the main reason I want to change the module name is because I use the jboss-marshalling to serialize some java objects and the ModularClassResolver includes these modules informations (name and slot), making the serializated data not compatible when we change the project version and the.war file has another. The embedded server can be reinitialized with a different JBoss Home. However the module directory, module.path system property, and the modules system packages, jboss.modules.system.pkgs system property, are effectively static. This means that creating a new embedded server or host controller within the same VM will not allow overriding the. A global module is a module that JBoss Enterprise Application Platform 6 provides as a dependency to every application. Any module can be made global by adding it to the application server's list of global modules. You can easily add global modules from the management console (see sources), or by editing the standalone.xml.

• JBoss Modules Documentation (old) https://docs.jboss.org/author/display/MODULES/Home
• Binaries https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/modules/jboss-modules/
• JIRA https://issues.jboss.org/projects/MODULES
• Layered Distributions and Module Path Organization by Brian Stansberry https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization

A WildFly module (or JBoss module) is a packaged collection of classes and other resources, along with the specification of what is imported and exported by this module from/to other modules. Each API or service provided by WildFly is implemented as a module, which is loaded or unloaded on demand.

WildFly modules provide finely grained class isolation. They hide server implementation classes from the application and only load the classes the application needs. WildFly modules are peers that remain isolated unless explicitly defined as a dependency of another module. Visibility rules have sensible defaults and can be customized.

JEE deployments (see below) are also modules, which do not have access to application server modules' classes, unless an explicit dependency on those classes is defined.

For more details on class loading see

WildFly class loading

TODO: how can I get a list (hierarchy) of all modules deployed within an instance, at runtime?

Statically deployed modules go under $JBOSS_HOME/modules directory.

Each module has a module.xml descriptor.

Standalone WAR Deployments

A WAR deployment creates a single module at runtime. Classes defined in WEB-INF/lib and WEB-INF/classes are added to the classpath and are treated similarly from a visibility point of view. All classes packaged in the WAR will be loaded by the same class loader. The name of the module is 'deployment.some-servlet.war', where 'some-servlet.war' is the name of the deployment artifact. More about deployment module names available here: Deployment Module Names.

Standalone EJB Deployments

Jboss Global Module Sloth

An EJB JAR deployment creates a single module at runtime. The name of the module is 'deployment.stateless-ejb-example.jar', where 'stateless-ejb-example.jar' is the name of the deployment artifact. More about deployment module names available here: Deployment Module Names.

Jboss Global Module Slot Tool

EAR Deployments

An EAR deployment creates multiple modules:

• One module corresponding to EAR's /lib directory.
• Modules corresponding to every WAR and EJB deployments. These have an automatic dependency on the parent EAR module, which gives them automatic access to EAR's /lib content.

The name of the EAR module is similar to: 'deployment.my-ear-2.0.ear'. If the EJB was deployed within an EAR, the name is similar to 'deployment.my-ear-app-2.0.ear.my-ejb-services-2.0.jar'. For more details on the names, see Deployment Module Names below.

The modules corresponding to embedded WARs and JARs are created and deployed in parallel, on multiple 'MSC service thread-*'s.

Because the deployment process creates distinct modules corresponding to the WAR and EJB deployments, not all classes inside the EAR will necessarily have access to all other classes in the EAR, unless explicit dependencies have been defined or 'ee' subystem's configuration parameter ear-subdeployments-isolated is set to false. For more details on ear-subdeployments-isolated see:

'ee' Subsystem ear-subdeployments-isolated

Dependencies: Manifest Entries

TODO, see https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-EARClassLoading.

Also see:

MANIFEST.MF

Class-Path: Manifest Entries

TODO, see https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-ClassPathEntries.

Also see:

MANIFEST.MF

Deployment Module Names

Each JEE deployment triggers run-time initialization of corresponding module or set of modules.

A top-level deployment that does not have any other sub-deployments creates a single module named deployment.<my-archive-name>.war:<version>.

Example for a simple servlet deployment:

Sub-deployments are named according to the following pattern: deployment.<my-ear-archive-name>.ear.<my-war-archive-name>.war.

Global Modules

It is possible to set up global modules that are accessible to all JEE deployments:

For more details on configuring global modules see:

Global Module configuration

'ee' Subsystem Configuration

For more details on 'ee' subsystem configuration see:

ee Subsystem Configuration

Playground Example

https://github.com/NovaOrdis/playground/tree/master/jboss/wildfly/module-dependency

Implicit Dependencies

Some dependencies on modules defined by the application server are set up automatically for JEE deployments, making them implicit dependencies. An obvious example is JEE APIs. When a deployment is being processed by the server, it goes through a chain of deployment processors. Each of these processors has the option to add implicit module dependencies to that deployment. For example, the presence of the @Stateless annotation identifies this deployment as an EJB deployment to the EJB deployment processor, so the processor will add an implicit dependency on the Java EE API module, so that all the Java EE API classes are visible to the deployment.

Automatic dependencies can be excluded through the use of the jboss-deployment-structure.xml deployment descriptor.

More details on Implicit module dependencies for deployments are available here:

https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments

The list of dependencies can be obtained by turning on org.jboss.module DEBUG.

Explicit Dependencies

Jboss Global Module Slots

Dependencies on other modules can (and must) be expressed explicitly. The most common way to do that is to declare the dependency on the module in jboss-deployment-structure.xml

Declaring a dependency on another module in jboss-deployment-structure.xml

The dependency on a module can also be declared in the MANIFEST.MF of the JAR containing the classes that need to access the module. More details available here

How to specify a dependency on a JBoss Module in JBoss EAP 6/7 https://access.redhat.com/solutions/341703

If we need to express a dependency across a number of JEE deployments, global modules could help:

Global Modules

Expressing a Dependency on a Dynamic Module

It is possible for a deployment to import classes - declare a dependency - on another deployment, using the other deployment's dynamic module name:

JDK Classes

sun.jdk is automatically added as a dependency to all deployments, but not all JDK classes are exposed to deployments by default, but specific classes or packages can be added as dependencies using jboss-deployment-structure.xml.

See:

jboss-deployment-structure.xml - accessing JDK Classes

Writing a Custom WildFly Module

https://github.com/dmlloyd/jboss-modules

• Upon the first use of the module, JBoss creates a <module-name>.jar.index file containing a list of packages? directories? .... .

• Version slot identifiers are used when you wish to have more than one instance of a module in a module loader under the same name. This may occur when introducing a new major version of a module which is not API-compatible with the old version but is used by newer applications. A version slot identifier is an arbitrary string; thus one can use just about any system they wish for organization. If not otherwise specified, the version slot identifier defaults to 'main'. When identifying a module in a string, the version slot identifier can be appended to the module name, separated by a colon ':'.

Jboss Global Module Slot Reset

• Can modules be hot-(re)deployed?