术语
Deployment
部署在AS7中的ear、war等都被称作为deployment。
简介
JBoss AS7（以下简称AS7）的class loader机制与JBoss之前的版本有很大的不同。AS7的classloading是在JBoss Modules项目中实现的。与之前的扁平化的双亲委托机制不同，AS7的classloading是基于module的，一个module如果想要“看见”另一个module，必须要显式地定义依赖关系。部署在AS7中ear、war也被看作是module，如果ear或者war没有显式地定义对AS7自带的jar的依赖的话，那么是“看不见”容器的jar的。
deployment的module名称
- war的module name为： deployment.myarchive.war
- ear中的war的module name为： deployment.myear.ear.mywar.war
自动依赖
如果让ear必须显式地定义AS7每一个JEE规范的jar的依赖的话，显然是没有必要的，因此AS7在部署一个ear时，会自动为deployment添加上一些依赖，而不用ear手工指定。比如ear中包含persistence.xml，那么AS7会自动为其添加JPA module的依赖，再比如ear中包含@Stateless的ejb时，AS7会自动为其添加ejb module的依赖。
如果ear想exclude掉AS7启动添加的依赖，可以在META-INF/jboss-deployment-structure.xml中添加exclude。
class loading的顺序
在以往的JBoss版本中，当ear中包含了xx-version1.jar的同时，容器也存在xx-version2.jar的话，就会出问题，也就是不同版本的jar不能共存。为了解决这个问题，AS7中定义了class loading的顺序。
class loading的优先级从高到低：
- AS7自动添加的依赖
- jboss-deployment-structure.xml中定义的
- WEB-INF/classes 或者 WEB-INF/lib
- deployment之间的依赖，比如ear中的waru依赖ear中的ejb
war的class loading
由于一个war被当作是一个module，所以war中的WEB-INF/lib与WEB-INF/classes是平等的，两者中的class被同一个classloader加载
ear classloading
假设ear的结构是：
1 2 3 4 5 6 7 | myapp.ear | |--- web.war | |--- ejb1.jar | |--- ejb2.jar
|
AS7默认行为是：
- web.war能看见ejb1.jar与ejb2.jar
- ejb1.jar与ejb2.jar能互相看见
如果standalone.xml中的ear-subdeployments-isolated设为了true，则web.war、ejb1.jar、ejb2.jar就互相看不见了。
1 2 3 | <subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>
|
global modules
可以在ee subsystem中设置所有deployment都依赖的module，例如：
1 2 3 4 5 | <subsystem xmlns="urn:jboss:domain:ee:1.0" > <global-modules> <module name="org.javassist" slot="main" /> </global-modules> </subsystem>
|
jboss-deployment-structure.xml文件
jboss-deployment-structure.xml 是JBoss特有的一个文件，用于细粒度地控制class loading，应该放入META-INF文件夹中。jboss-deployment-structure.xml可以做到：
- exclude掉AS7自动添加的依赖
- 显式地添加对现有module的依赖
- 定义额外的module
- 改变EAR deployments isolated行为
示例如下：（详见xml schema）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 | <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>
|
Reference：