jbossクラスのロード順序:1)システムパッケージ2)jboss-deployment-structure.xmlまたはDependencies:manifest entry for modulesまたはthrough Class-Path:for jar files.3)ローカルパッケージWEB-INF/classesとWEB-INF/libの下のコンテンツ4)内部依存クラス:earのようなサブパッケージ相互依存アプリケーションモジュールにロードされた命名規則:deployment.myarchive.war ,deployment.myear.ear.mywar.war.あまり説明しないで、観察の下で特徴.システムのパケットは自動ロードに依存する.注意1つのパケットがアプリケーションとjbossシステムの両方にある場合、hostが優先的に使用される.xmlに配置するサブシステムの依存パケット.腰でこのようなシステムパケットとの依存性を変えるとjboss-deployment-structureを配置することができる.xmlファイル EARパッケージ内のすべてのサブシステムのクラスおよびパッケージは、共有および排他に設定できます.でもhost.xmlで排他的に構成され、デフォルトでは共有されます.すなわち、他のサブプロジェクトからクラスをロードできます:false warのlibファイルとclassファイルはjbossで同等に扱われるです.
jboss-deployment-structure.xmlの役割は、最上位アプリケーションにパケットを追加または削除することです.ファイル側はMETA-INF(またはWEB-INF)に置く. 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 -->
<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>
グローバル依存性を設定できます: