Added by Stuart Douglas, last edited by Daniel De Leon on Dec 03, 2012 (view change)
Go to start of metadata
Class loading in AS7 is considerably different to previous versions of JBoss AS. Class loading is based on theJBoss Modules project. Instead of the more familiar hierarchical class loading environment, AS7's class loading is based on modules that have to define explicit dependencies on other modules. Deployments in AS7 are also modules, and do not have access to classes that are defined in jars in the application server unless an explicit dependency on those classes is defined.
Deployment Module Names
Module names for top level deployments follow the format deployment.myarchive.war while sub deployments are named likedeployment.myear.ear.mywar.war.
This means that it is possible for a deployment to import classes from another deployment using the other deployments module name, the details of how to add an explicit module dependency are explained below.
Automatic Dependencies
Even though in AS7 modules are isolated by default, as part of the deployment process some dependencies on modules defined by the application server are set up for you automatically. For instance, if you are deploying a Java EE application a dependency on the Java EE API's will be added to your module automatically. Similarly if your module contains a beans.xml file a dependency onWeld will be added automatically, along with any supporting modules that weld needs to operate.
For a complete list of the automatic dependencies that are added see this page.
Automatic dependencies can be excluded through the use of jboss-deployment-structure.xml.
Class Loading Precedence
A common source of errors in Java applications is including API classes in a deployment that are also provided by the container. This can result in multiple versions of the class being created and the deployment failing to deploy properly. To prevent this in AS7, module dependencies are added in a specific order that should prevent this situation from occurring.
In order of highest priority to lowest priority
System Dependencies - These are dependencies that are added to the module automatically by the container, including the Java EE api's.
User Dependencies - These are dependencies that are added through jboss-deployment-structure.xml or through the Dependencies: manifest entry for modules or through Class-Path: for jar files.
Local Resource - Class files packaged up inside the deployment itself, e.g. class files fromWEB-INF/classes or WEB-INF/lib of a war.
Inter deployment dependencies - These are dependencies on other deployments in an ear deployment. This can include classes in an ear's lib directory, or classes defined in other ejb jars.
WAR Class Loading
The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes inWEB-INF/classes. All classes packaged in the war will be loaded with the same class loader.
EAR Class Loading
Ear deployments are multi-module deployments. This means that not all classes inside an ear will necessarily have access to all other classes in the ear, unless explicit dependencies have been defined. By default theEAR/lib directory is a single module, and every WAR or EJB jar deployment is also a separate module. Sub deployments (wars and ejb-jars) always have a dependency on the parent module, which gives them access to classes inEAR/lib, however they do not always have an automatic dependency on each other. This behaviour is controlled via theear-subdeployments-isolated setting in the ee subsystem configuration:
<
subsystem
xmlns
=
"urn:jboss:domain:ee:1.0"
>
<
ear-subdeployments-isolated
>false</
ear-subdeployments-isolated
>
</
subsystem
>
By default this is set to false, which allows the sub-deployments to see classes belonging to other sub-deployments within the .ear.
For example, consider the following .ear deployment:
myapp.ear
|
|--- web.war
|
|--- ejb1.jar
|
|--- ejb2.jar
If the ear-subdeployments-isolated is set to false, then the classes in web.war can access classes belonging to ejb1.jar and ejb2.jar. Similarly, classes from ejb1.jar can access classes from ejb2.jar (and vice-versa).
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
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. This is as per spec.
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 withClass-Path entries, or by setting up explicit module dependencies.
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
Portability
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.
Class-Path: /X:/libs/libFile.jar
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
It is also possible to override the ear-subdeployments-isolated element value at a per deployment level. See the section on jboss-deployment-structure.xml below.
Dependencies: Manifest Entries
Deployments (or more correctly modules within a deployment) may set up dependencies on other modules by adding aDependencies: manifest entry. This entry consists of a comma separated list of module names that the deployment requires. The available modules can be seen under themodules directory in the application server distribution. For example to add a dependency on javassist and apache velocity you can add a manifest entry as follows:
Each dependency entry may also specify some of the following parameters by adding them after the module name:
export This means that the dependencies will be exported, so any module that depends on this module will also get access to the dependency.
services By default items in META-INF of a dependency are not accessible, this makes items fromMETA-INF/services accessible so services in the modules can be loaded.
optional If this is specified the deployment will not fail if the module is not available.
annotations If a jandex index has be created for the module these annotations will be merged into the deployments annotation index. TheJandex index can be generated using the Jandex ant task , and must be named META-INF/jandex.idx. Note that it is not necessary to break open the jar being indexed to add this to the modules class path, a better approach is to create a jar containing just this index, and adding it as an additional resource root in the module.xml file.
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
Adding a dependency to all modules in an EAR
Using the export parameter it is possible to add a dependency to all sub deployments in an ear. If a module is exported from aDependencies: entry in the top level of the ear (or by a jar in the ear/lib directory) it will be available to all sub deployments as well.
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
To generate a MANIFEST.MF entry when using maven put the following in your pom.xml: pom.xml
<
build
>
...
<
plugins
>
<
plugin
>
<
groupId
>org.apache.maven.plugins</
groupId
>
<
artifactId
>maven-war-plugin</
artifactId
>
<
configuration
>
<
archive
>
<
manifestEntries
>
<
Dependencies
>org.slf4j</
Dependencies
>
</
manifestEntries
>
</
archive
>
</
configuration
>
</
plugin
>
</
plugins
>
</
build
>
If your deployment is a jar you must use the maven-jar-plugin rather than themaven-war-plugin.
Class Path Entries
It is also possible to add module dependencies on other modules inside the deployment using theClass-Path manifest entry. This can be used within an ear to set up dependencies between sub deployments, and also to allow modules access to additional jars deployed in an ear that are not sub deployments and are not in theEAR/lib directory. If a jar in the EAR/lib directory references a jar viaClass-Path: then this additional jar is merged into the parent ear's module, and is accessible to all sub deployments in the ear.
Global Modules
It is also possible to set up global modules, that are accessible to all deployments. This is done by modifying the configuration file (standalone/domain.xml).
For example, to add javassist to all deployments you can use the following XML:
standalone.xml/domain.xml
<
subsystem
xmlns
=
"urn:jboss:domain:ee:1.0"
>
<
global-modules
>
<
module
name
=
"org.javassist"
slot
=
"main"
/>
</
global-modules
>
</
subsystem
>
Note that the slot field is optional and defaults to main.
JBoss Deployment Structure File
jboss-deployment-structure.xml is a JBoss specific deployment descriptor that can be used to control class loading in a fine grained manner. It should be placed in the top level deployment, inMETA-INF (or WEB-INF for web deployments). It can do the following:
Prevent automatic dependencies from being added
Add additional dependencies
Define additional modules
Change an EAR deployments isolated class loading behaviour
Add additional resource roots to a module
An example of a complete jboss-deployment-structure.xml file for an ear deployment is as follows:
jboss-deployment-structure.xml
<
jboss-deployment-structure
xmlns
=
"urn:jboss:deployment-structure:1.2"
>
<!-- Make sub deployments isolated by default, so they cannot see each others classes without a Class-Path entry -->
<
ear-subdeployments-isolated
>true</
ear-subdeployments-isolated
>
<!-- This corresponds to the top level deployment. For a war this is the war's module, for an ear -->
<!-- This is the top level ear module, which contains all the classes in the EAR's lib folder -->
<
deployment
>
<!-- exclude-subsystem prevents a subsystems deployment unit processors running on a deployment -->
<!-- which gives basically the same effect as removing the subsystem, but it only affects single deployment -->
<
exclude-subsystems
>
<
subsystem
name
=
"resteasy"
/>
</
exclude-subsystems
>
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
<
exclusions
>
<
module
name
=
"org.javassist"
/>
</
exclusions
>
<!-- This allows you to define additional dependencies, it is the same as using the Dependencies: manifest attribute -->
<
dependencies
>
<
module
name
=
"deployment.javassist.proxy"
/>
<
module
name
=
"deployment.myjavassist"
/>
<!-- Import META-INF/services for ServiceLoader impls as well -->
<
module
name
=
"myservicemodule"
services
=
"import"
/>
</
dependencies
>
<!-- These add additional classes to the module. In this case it is the same as including the jar in the EAR's lib directory -->
<
resources
>
<
resource-root
path
=
"my-library.jar"
/>
</
resources
>
</
deployment
>
<
sub-deployment
name
=
"myapp.war"
>
<!-- This corresponds to the module for a web deployment -->
<!-- it can use all the same tags as the <deployment> entry above -->
<
dependencies
>
<!-- Adds a dependency on a ejb jar. This could also be done with a Class-Path entry -->
<
module
name
=
"deployment.myear.ear.myejbjar.jar"
/>
</
dependencies
>
<!-- Set's local resources to have the lowest priority -->
<!-- If the same class is both in the sub deployment and in another sub deployment that -->
<!-- is visible to the war, then the Class from the other deployment will be loaded, -->
<!-- rather than the class actually packaged in the war. -->
<!-- This can be used to resolve ClassCastExceptions if the same class is in multiple sub deployments-->
<
local-last
value
=
"true"
/>
</
sub-deployment
>
<!-- Now we are going to define two additional modules -->
<!-- This one is a different version of javassist that we have packaged -->
<
module
name
=
"deployment.myjavassist"
>
<
resources
>
<
resource-root
path
=
"javassist.jar"
>
<!-- We want to use the servers version of javassist.util.proxy.* so we filter it out-->
<
filter
>
<
exclude
path
=
"javassist/util/proxy"
/>
</
filter
>
</
resource-root
>
</
resources
>
</
module
>
<!-- This is a module that re-exports the containers version of javassist.util.proxy -->
<!-- This means that there is only one version of the Proxy classes defined -->
<
module
name
=
"deployment.javassist.proxy"
>
<
dependencies
>
<
module
name
=
"org.javassist"
>
<
imports
>
<
include
path
=
"javassist/util/proxy"
/>
<
exclude
path
=
"/**"
/>
</
imports
>
</
module
>
</
dependencies
>
</
module
>
</
jboss-deployment-structure
>
jboss7靜态變量由于不同的類加載器在兩個子產品中不相同Class Loading in AS7
The xsd for jboss-deployment-structure.xml is available at https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-deployment-structure-1_2.xsd
Accessing JDK classes
Not all JDK classes are exposed to a deployment by default. If your deployment uses JDK classes that are not exposed you can get access to them using jboss-deployment-structure.xml with system dependencies:
Using jboss-deployment-structure.xml to access JDK classes
