Jboss Global Module Slot
- 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.
- Copy the following contents of the application that you are currently deploying to the JBoss modules directory. Atlas Policy Suite server Copy the contents of the AltasHome Atlas setup jboss-6-eap modules directory to the JBossHome modules directory. Atlas Extensions.
- A collection of tutorials for configuration and management of WildFly and Jboss application server AS 7.
Community Blog Feed: Most Recent Posts
The slot attribute is for specifying the version of the module you want to include, it defaults to main when not specified.
This Week in JBoss - 17 December 2020
17 December 2020
THIS WEEK IN JBOSS - 17 DECEMBER 2020 Welcome to another installment of our JBoss Editorial and last before the holidays! As always during this period of the year, we all rush to finish our ongoing tasks so that we can enjoy a bit of rest. And th…
Quarkus 1.10.3.Final released - Bugfixes
8 December 2020
1.10.3.Final is a maintenance release fixing bugs and improving the documentation. Thanks to all the contributors who reported issues and provided reproducers: it really helped a lot! It is a safe upgrade for everyone using Quarkus 1.10. If you are …
Using Avro in a native executable
8 December 2020
A few months back, I blogged about Quarkus, Kafka, and Avro (using the Apicurio schema registry). We developed a simple application, receives HTTP requests, writes Kafka records, and reads them from Kafka. It uses Avro to serialize and deserialize t…
CodeReady Containers - Installing business automation operator (Part 2)
7 December 2020
As a consistent user and developer on the OpenShift platform over the years, I’ve tried helping users by sharing my application development content as we’ve journeyed from cartridges all the way to container base development. With container based de…
Announcing RESTEasy Reactive
7 December 2020
It gives the Quarkus and RESTEasy teams great pleasure to announce that RESTEasy Reactive integration in Quarkus has landed in the main Quarkus repo [1] and will be part of the next Quarkus release 1.11. We are looking forward to everyone testing it…
Extension codestarts - A new way to learn & discover Quarkus
7 December 2020
What’s nice about Extension codestarts is that it’s useful for fresh Quarkus developers as well as experienced ones. This is because of the wide range (and growing) of Quarkus extensions, you simply can’t know them all. When I am comparing framework…
Quarkiverse Hub - Home of Community Extensions
3 December 2020
Today we’re proud to announce Quarkiverse Hub, a GitHub organization where any contributor can host their Quarkus extensions. Hosting your extension in the Quarkiverse Hub makes it available to all Quarkus users through the Quarkus tooling. So read …
This Week in JBoss - 16 September 2020
3 December 2020
THIS WEEK IN JBOSS - 16 SEPTEMBER 2020 Hello! Welcome to another edition of the JBoss Editorial that brings you news and updates from our community. RELEASES! is out! This release brings several updates, notably JSON as the default media typ…
CodeReady Containers - Installing business automation operator (Part 1)
2 December 2020
As a consistent user and developer on the OpenShift platform over the years, I’ve tried helping users by sharing my application development content as we’ve journeyed from cartridges all the way to container base development. With container based de…
Quarkus 1.10 released - JSON as default, Multiple reactive datasources, new Micrometer registries…
1 December 2020
The just released Quarkus 1.10.2.Final comes with a lot of improvements and new features: Default media type is now JSON CodeStarts is now the default project generation tool The Micrometer extension got its fair share of improvements (e.g. new regi…
Sending and Receiving Cloud Events with Kafka
1 December 2020
Cloud Events is a specification for describing events. It aims to ease interoperability. With the rise of event-driven architecture, it’s not surprising to see Cloud Events gaining popularity. This post explains how you can generate and consume Clou…
WildFly MicroProfile GraphQL Feature Pack 1.0.0.Final Released!
27 November 2020
I am happy to announce that the first Final build of the GraphQL feature pack has been released! It is fully compatible with MicroProfile GraphQL 1.0 and has been tested with WildFly 20 and 21, JDK 8 and 11. It bundles the latest available version o…
Stylish API
25 November 2020
In this blog post we are going to look at the new styling and other new options available in OpenAPI and Swagger UI Quarkus extensions (version 1.10+). All the source code for the examples below is available here. Styling Default style The default s…
I hate distributed locks!
24 November 2020
I hate distributed locks! Adding distributed locks to JGroups has been the second biggest mistake that I’ve made (next to MuxRpcDispatcher). Unfortunately, a lot of people are using them in JGroups… Distributed locks don’t work. Or, at least, don'…
Installing Fedora 33 on Macbook Pro 13 inch (late 2011)
24 November 2020
This weekend I stumbled on an old Macbook Pro 13 inch from late 2014, with 125GB SSD and 8GB RAM. It’s a machine I’ve taken on trips around the world and back in the day ran many a session, workshop, or demo on sharing all that AppDev goodness you k…
Eclipse Vert.x 4 CR2 released!
24 November 2020
We are extremely pleased to announce the first release candidate of Vert.x 4.0 . We consider Vert.x 4.0 as feature complete and we will do a few release candidates to allow the community to test it and report issues. Vert.x 4 is the evolution of the…
Mutiny and the Reactiverse
24 November 2020
I had the question multiple times: how do I use Eclipse Vert.x in Quarkus? Indeed, you can use Vert.x in Quarkus. You can deploy verticles, communicate with the event bus, or use anything from the Vert.x ecosystem. But, you can also use the Mutiny v…
Untangling Reactive Streams' Gordian Knot, Wiring Subscriber, Publisher and Subscription
23 November 2020
This week in JBoss - 20th November 2020
20 November 2020
THIS WEEK IN JBOSS - 20TH NOVEMBER 2020 Welcome to another installment of our JBoss Editorial! Today, we’ll focus on some core project of our community. The first one is obviously Wildfly, our Jakarta EE application server whom predecessor (JBoss…
- End of Results -
- 6JEE Deployment Modules
- 6.3EAR Deployments
- 7Inter-Module Dependencies
- 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
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.
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
Jboss Global Module Slot Reset
'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:
Jboss Global Module Slot Programming
- 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
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
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
- Declaring a dependency on another module in jboss-deployment-structure.xml
- 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? .... .
Jboss Global Module Slot Key
- 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 ':'.
- Can modules be hot-(re)deployed?