jboss module依賴 問題

問題來源於 ovirt部署在jboss中，所用到的版本Jboss版本以下。

JBoss AS release: 7.5.4.Final-redhat-4 "Janus"
JBoss AS product: EAP 6.4.4.GA

而在咱們開發的過程當中，須要引入第三方的jar包，出現了不少問題，經過官網上的文檔，以及各類嘗試終於解決了如下幾種場景的jar包引入的問題。

對於Jboss而言，有其類自定的類加載機制。全部的jar包都是一個module,因此須要以moudle的形式引入。而jboss又默認提供了一些通用的module，而對於jboss環境中沒有提供的module，就須要咱們本身在項目中生成一個module。分兩種狀況

1. 系統提供的 static   module     多種應用 就可使用同一個公用的jar。

   1. jboss目錄中的modules文件夾下就提供了module，
   2. /jbossas/modules/system/layers/base/  目錄下，就是提供了各module
   3. 如 commons-io，目錄結構以下，

      [root@localhost main]# ls
      commons-io.jar  module.xml
      [root@localhost main]# pwd
      /usr/share/jbossas/modules/system/layers/base/org/apache/commons/io/main

      而該commons.jar指向了commons-io.jar -> /usr/share/java/commons-io-eap6/commons-io.jar ，而該版本爲2.1.
   4. 若是咱們須要在ovirt中引用commos-io的jar包，有兩種方式，第一種是使用系統提供的module，則版本只能爲2.1,而若是 不想使用系統提供的。則使用下面第二種方式，本身建立module。
   5. 而對於第一種引用，則直接在對應的project的 pom.xml引用相關的配置便可，version爲2.1。
      1. 同時因爲jboss的依賴問題，還須要在對應的MANIFEST.MF文件中添加Dependencies:commons-io。
      2. 或者在pox.xml中加入自動 生成的依賴

      3. <manifestEntries> <Dependencies>org.apache.commons.io</Dependencies></manifestEntries>

          

2. 本身建立moudule

   1. 對於第三方的jar包，jboss沒有提供的狀況下，則須要在相應的project下，按照相應的目錄格式，建立相應的modules.xml。同時將jar包傳入便可，也能夠經過pom.xml的形式導入.

3. 對於依賴傳遞問題，A-B-C

如下摘自jboss官網文檔

Module A depends on Module B and Module B depends on Module C. Module A can access the classes of Module B, and Module B can access the classes of Module C. Module A cannot access the classes of Module C unless:

• Module A declares an explicit dependency on Module C, or

• Module B exports its dependency on Module C.

若是A依賴於B，B依賴於C，A須要用到C，則須要在A的module中寫入對C的依賴，或者在B的module中將C導出。

4.    Class Loading in Deployments

For the purposes of classloading all deployments are treated as modules by JBoss EAP 6. These are called dynamic modules. Class loading behavior varies according to the deployment type.

WAR Deployment

A WAR deployment is considered to be a single module. Classes in the WEB-INF/lib directory are treated the same as classes in WEB-INF/classes directory. All classes packaged in the war will be loaded with the same class loader.

EAR Deployment

EAR deployments are made up more than one module. The definition of these modules follows these rules:

1. The lib/ directory of the EAR is a single module called the parent module.

2. Each WAR deployment within the EAR is a single module.

3. Each EJB JAR deployment within the EAR is a single module.

Subdeployment modules (the WAR and JAR deployments within the EAR) have an automatic dependency on the parent module. However they do not have automatic dependencies on each other. This is called subdeployment isolation and can be disabled on a per deployment basis or for the entire application server.

Explicit dependencies between subdeployment modules can be added by the same means as any other module.

Report a bug

5. Class Loading Precedence

The JBoss EAP 6 modular class loader uses a precedence system to prevent class loading conflicts.

During deployment a complete list of packages and classes is created for each deployment and each of its dependencies. The list is ordered according to the class loading precedence rules. When loading classes at runtime, the class loader searches this list, and loads the first match. This prevents multiple copies of the same classes and packages within the deployments class path from conflicting with each other.

The class loader loads classes in the following order, from highest to lowest:

1. Implicit dependencies.

   These are the dependencies that are added automatically by JBoss EAP 6, such as the JAVA EE APIs. These dependencies have the highest class loader precedence because they contain common functionality and APIs that are supplied by JBoss EAP 6.

   Refer to Section 3.7.1, 「Implicit Module Dependencies」 for complete details about each implicit dependency.

2. Explicit dependencies.

   These are dependencies that are manually added in the application configuration. This can be done using the application's MANIFEST.MF file or the new optional JBoss deployment descriptor jboss-deployment-structure.xml file.

   Refer to Section 3.2, 「Add an Explicit Module Dependency to a Deployment」 to learn how to add explicit dependencies.

3. Local resources.

   Class files packaged up inside the deployment itself, e.g. from the WEB-INF/classes or WEB-INF/libdirectories of a WAR file.

4. Inter-deployment dependencies.

   These are dependencies on other deployments in a EAR deployment. This can include classes in the libdirectory of the EAR or classes defined in other EJB jars.

 

 

 

https://access.redhat.com/documentation/zh-CN/JBoss_Enterprise_Application_Platform/6.1/html/Migration_Guide/Find_the_JBoss_Module_Dependency1.html    查找 JBoss 模塊依賴關係

 

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html/Development_Guide/chap-Class_Loading_and_Modules.html#Overview_of_Class_Loading_and_Modules-1

https://my.oschina.net/iwuyang/blog/197231

http://jbosscn.iteye.com/blog/1143426  jboss modules介紹

http://blog.csdn.net/andyelvis/article/details/6719996 tomcat classpath 類加載介紹