WildFly Modules: Difference between revisions
| Line 109: | Line 109: | ||
</subsystem> | </subsystem> | ||
</pre> | </pre> | ||
=="ee" Subsystem Configuration== | |||
For more details on "ee" subsystem configuration see: | |||
[[WildFly ee Subsystem|ee Subsystem]] | |||
=Inter-Module Dependencies= | =Inter-Module Dependencies= | ||
Revision as of 23:03, 18 March 2016
External
- 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
Internal
Overview
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 and 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 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.
Operations
TODO: how can I get a list (hierarchy) of all modules deployed within an instance, at runtime?
JEE Deployment Modules
WAR Deployments
A WAR deployment creates a single module at runtime. Classes defined in WEB-INF/lib and WEB-INF/classes are treated similarly from a visibility point of view. All classes packaged in the WAR will be loaded by the same class loader.
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.
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.
ear-subdeployments-isolated
As noted above, the default behavior of the application server is to isolate EAR sub-deployments, so classes from a sub-deployment do not have by default access to classes from other sub-deployment. This behavior can be configured via ear-subdeployments-isolated setting of the ee subdomain. By default, the value is implicitly true. It can be changed as follows:
<subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>
The ear-subdeployments-isolated element value has no effect on the isolated classloader of the WAR file(s). i.e. irrespective of whether this flag is set to true or false, the WAR within a EAR will have an isolated classloader and other sub-deployments within that EAR will not be able to access classes from that WAR. JEE specifications mandate this behavior.
If the ear-subdeployments-isolated is set to true then no automatic module dependencies between the sub-deployments are set up. User must manually setup the dependency with Class-Path: entries, or by setting up explicit module dependencies. The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path: entry is set in the MANIFEST.MF. So portable applications should always use Class-Path: entry to explicitly state their dependencies.
The global ear-subdeployments-isolated setting can overridden in the jboss-deployment-structure.xml deployment descriptor.
Dependencies: Manifest Entries
TODO, see https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-EARClassLoading.
Also see:
Class-Path: Manifest Entries
TODO, see https://docs.jboss.org/author/display/AS71/Developer+Guide#DeveloperGuide-ClassPathEntries.
Also see:
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:
deployment.servlet-example.war:main
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:
<subsystem xmlns="urn:jboss:domain:ee:1.2">
<global-modules>
<module name="io.novaordis.playground.wildfly.custommodule" slot="1.0" />
</global-modules>
</subsystem>
"ee" Subsystem Configuration
For more details on "ee" subsystem configuration see:
Inter-Module Dependencies
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:
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
If we need to express a dependency across a number of JEE deployments, global modules could help:
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:
Writing a Custom WildFly Module
TODO
Next, continue migrating https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBossModules
Organizatorium
Upon the first use of the module, JBoss creates a <module-name>.jar.index file containing a list of packages? directories? .... .