Outline
From the JBoss AS7 start, Classloader start using this new JBoss Modules. This article briefly illustrate design ideas JBoss Modules, and give an example of this design concept.
JBoss Modules Introduction
As we all know, Java has been used classpath way to load various class and jar of resources. In this way will cause many problems, such problems frequently encountered the following:
- A large project, some of which classpath resources might not be used after being loaded, which resulted in a waste of system resources
- The same resources among a classpath, may contain multiple different versions of the same resource, which resulted in a version conflict, can cause the whole project can not run and difficult to troubleshoot, because our project can be very large, successful inside one hundred thousand jar, in order to find the resource conflict is very difficult
- By using module.xml module description file is defined, in this description to include file name of the module, which contains resources (typically a jar file corresponds to a module, may include a plurality jar or other resources), the version number of these resources and this module depend on which modules.
- Each module can be loaded in real-time or relieved. This has many advantages: First, resources saving, only the modules needed was only loaded (and this is achieved by dependencies between modules module.xml defined), while this approach to bring the benefits of is: loading speed of the system greatly enhanced
JBoss Modules definitions
JBoss Modules for Java is a modular (non-hierarchical) class loader and the realization of the execution environment. In other words, unlike the traditional use of a single Java class loader to load the classpath all JAR files, each of a library (Library, be appreciated that the jar to complete the series combination of a function of a) into a module, the module only Links to other module on which it relies, rather than rely on any other resources. JBoss Module implements a thread-safe, fast, high concurrency class loader delegate (delegating) model, coupled with a scalable analytical engine modules to form a unique, simple and powerful application execution and distribution system.
JBoss Modules is designed to be able to work together without the need for any modifications and existing library or application, because it is simple and name resolution policy. Unlike OSGi, JBoss Modules did not achieve a container; start but a thin wrapper, an application executed in a modular environment. At this point, your application takes control, modular loading and is ready to connect the module when needed. Further, only when a module is dependent on the time, it will be loaded (not loaded for analytical purposes), which means that the performance of modular applications depends only on the number of modules actually used (and module when used), rather than the total number of modules in the system. Further, the module can be unloaded at any time by the user.
JBoss Modules use
A modular program started using the following command:
java -jar jboss-modules.jar -mp path/to/modules my.main.module.nameYou need to specify the default module in the module loading path (-mp) search elements required to load the root directory module. my.main.module.name specify the name of the module to run.
A module using a simple XML descriptor is defined as:
<module xmlns="urn:jboss:module:1.0" name="org.jboss.msc">
<main-class name="org.jboss.msc.Version"/>
<resources>
<resource-root path="jboss-msc-1.0.0.Beta3.jar"/>
</resources>
<dependencies>
<module name="org.jboss.logging"/>
<!-- Optional deps -->
<module name="javax.inject.api" optional="true"/>
<module name="org.jboss.threads" optional="true"/>
<module name="org.jboss.vfs" optional="true"/>
</dependencies>
</module>There is a schema file in jboss-moduels.jar in module descriptors to define the format, so integrated into your favorite IDE will be easy. JBoss Moduels provides many extended features to strictly control what java package is "exported" or "imported ', so you can selectively does not contain some of the resources from your Jar file (this will change when using pre-packaged jar file even more simple).
JBoss Modules 与 OSGI
JBoss Modules compared with OSGI:
- JBoss Modules easier. A Jar file is all you need to run modular applications.
- It is more compact: no osgi of sevice layer, or other higher-level functions provided by the OSGI. It only do one thing and do it well.
- At the same time, it's very functional and strong. It can be a class loading framework that can be used OSGI implementation.
Examples
This example code is in https://github.com/kylinsoong/wildfly-architecture/tree/master/modules/quickstart .
The foregoing Software Download and installation compiled to run by the command gituhb mounting part of the code for an example:
cd wildfly-architecture/modules/quickstart/
mvn clean dependency:copy-dependencies install
ant
[kylin@localhost bin]$ ./quickstart.sh
Welcome to Modular Class Loading QuickStart 1.0.0This example is simulated JBoss 7 start, then I explain the process started:
quickstart.sh specified in the startup module is org.jboss.modules.quickstart:
if [ "x$LAUNCH_DEMO_IN_BACKGROUND" = "x" ]; then
# Execute the JVM in the foreground
eval \"$JAVA\" $JAVA_OPTS \
-Ddemo.home.dir=\"$DEMO_HOME\" \
-jar \"$DEMO_HOME/jboss-modules-1.3.0.Beta3.jar\" \
-mp \"$DEMO_HOME/modules\" \
org.jboss.modules.quickstart \
"$@"
DEMO_STATUS=$?QuickStart / modules / system / layers / base / org / jboss / modules / quickstart / main / module.xml defined org.jboss.modules.quickstart following documents:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.modules.quickstart">
<main-class name="org.jboss.modules.quickstart.Main"/>
<resources>
<resource-root path="modules-quickstart.jar"/>
</resources>
<dependencies>
</dependencies>
</module>Similarly, we can also run this example uses java -jar way:
java -jar -mp modules/ org.jboss.modules.quickstartReproduced in: https: //my.oschina.net/iwuyang/blog/197231