JBoss低版本项目热部署到JBoss7

共计 11037 个字符，预计需要花费 28 分钟才能阅读完成。

1.        Jboss7 新特性
 
1.1 构建在 Modular Service Container 上，充分地利用了多核处理器的能力，并发、按需启动服务，启动速度更快、占用内存更小。
 
1.2 全面兼容 Java EE6
 
1.3 支持 JDK6/7
 
1.4 统一的配置和管理
 
1.5 兼容 OSGI 4.2，支持 OSGI 和 Java EE 组件模型集成。
 
1.6 容易测试：利用 Arquillian 测试平台—一种集成测试组件模型，更易于测试，改变 - 编译 - 测试的周期更短。
 
1.7 两种模式
 
Standalone 模式（使用 standalone.bat 启动）相当于以前的 3、4、5、6 版本。配置文件、发布内容等放在 standalone 目录下。
 
Domain 模式（使用 domain.bat 启动）是 Jboss7 的一个新特征，可以在一个控制点管理多个服务器。
 
1.8 类加载
 
类加载基于 Jboss Module，取代了层次类加载环境，避免了当类存在多个版本时，导致类加载错误。由于类加载是基于模块的，必须显示的定义模块依赖。部署也是模块化的，如果没有显示的定义类依赖则不能访问应用服务器 jar 中的类。
 
2.        迁移步骤
 
在 Jboss7 部署项目与在 jboss5 上有很大区别，最主要原因是由于类的加载模式改变了。Jboss5 部署相对简单，只需将相应的包部署到 lib 和 deploy 目录即可，类加载器会按层次自动加载，不用配置依赖关系。而 jboss7 完全不一样，jboss7 是按模块化加载，不同模块由不同类加载器加载，其他模块的 jar 包，对其是不可见的，这时需要手动配置包之间依赖关系，否则会报 ClassNotFoundException 等错误。另外对于数据源和 JNDI 的配置也发生了变化，所以把项目从 Jboss5 往 Jboss7 迁移时可以大概分为下述 3 个步骤：
 
2.1    依赖关系的配置
 
在 Jboss7 中，模块之间的依赖关系分为隐式依赖和显式依赖。
 
2.1.1 隐式依赖
 
尽管 Jboss7 中模块默认是隔离的，在部署过程中，一些由应用服务器定义的模块依赖会自动装配。例如，如部署一个 Java EE 应用，将自动添加 Java EE API 依赖，这也称为隐式模块依赖。
 
2.1.2 显式依赖
 
对于显式依赖，必须在 MANIFEST.MF 文件的“Dependencies:”或“Class-Path:”项或在 Jboss7 特有的部署文件 jboss-deployment-structure.xml 中显式定义。对于已有的项目，手动去查找各个模块之间的依赖关系是费时又费力的，可以通过 Tattletale 工具来分析，在分析报告的 OUTPUT_DIRECTORY/index.html 文件中点击 ”JBoss A7″ 则可以得到部分依赖关系，另外的依赖关系可以在“Depends On”中得到。
 
在 Jboss7 中类的加载优先级（从高到低）：
 
（1）系统依赖 - 服务器自动加载的模块依赖，包括 Java EE api。
 
（2）用户依赖 - 在 jboss-deployment-structure.xml（在 ear 的 META-INF 内，war 的 META-INF 或 WEB-INF 内）或 Dependencies: 项内配置的依赖。
 
（3）本地资源 - 发布目录下的类文件，如 war 包下的 WEB-INF/classes 或 WEB-INF/lib。
 
（4）部署间依赖 - 在 ear 内的其他部署依赖。包括 ear lib 目录内的类，或其他 ejb 包内的类。
 
在部署时，War 包被认为是一个单独的模块，WEB-INF/lib 和 WEB-INF/classes 内的类是相同的，都由同一类加载器加载。Ear 包是多模块的部署。这意味着不是 ear 内的所有类都能访问 ear 内所有其他类，除非指定明确的依赖。默认情况下，EAR/lib 目录是一个单独的模块，每个 WAR 或 EJB jar 是一个单独的模块。子部署 (war 和 ejb-jar) 总是依赖父模块，可以访问 EAR/lib 内的类，然而它们彼此间不总是有自动依赖。可以通过修改如下配置控制这个行为：
 
<subsystem xmlns=”urn:jboss:domain:ee:1.0″ >
 
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
 
</subsystem>
 
ear-subdeployments-isolated 默认值为 false，允许子部署访问其他子部署的类。在一个 Ear 包中，war 可以访问 jar 包里的类，jar 包之间也可以相互访问，但是 jar 包不能访问 war 包中的类，不管 ear-subdeployments-isolated 的值为 true 还是 false。
 
2.1.3 全局模块
 
可以把一些模块设置为全局模块，则所有的部署都可以访问该模块，在做项目迁移时，可以使用这种方法来解决模块依赖问题。格式如下:
 
<subsystem xmlns=”urn:jboss:domain:ee:1.0″/>
 
      <global-modules>
 
              <module name=”org.apache.log4j”/>
 
      </global-modules>
 
2.2    数据源配置
 
在 Jboss5 中，数据源的配置文件为 *-ds.xml 文件，该文件放在服务器的 deploy 目录下，其相应的 JDBC 驱动则放在服务器的 lib 目录或应用程序的 WEB-INF/lib 目录下。而在 Jboss7 中这些都不需要，配置文件为 Jboss7_home/standalone/configuration/standalone.xml 或者是 Jboss7_home/domain/configuration/domaion.xml。可以使用 IronJacamar 工具把原来的 *-ds.xml 文件转变为 Jboss7 中所需要的格式。
 
2.2.1          安装 JDBC 驱动
 
安装 JDBC 驱动分为两种方式：（1）作为一个部署（推荐的做法）（2）作为一个模块
 
2.2.1.1    作为一个部署
 
直接把 JDBC 驱动作为一个普通的 jar 包放在 deployment 目录下，该 JDBC 驱动应该是一个兼容 JDBC4（Jdbc 4 兼容的 driver 在 jar 包内含有 META-INF/services/java.sql.Driver 文件，其中指定了驱动类名称。）的驱动。若 JDBC 驱动包含不止一个 jar 包，则应作为一个模块来部署。
 
2.2.1.2    作为一个模块
 
需要在 modules 目录下创建一个目录结构，其内包含驱动 jar 包和 module.xml 文件。下面以安装 mysql 驱动为例，首先在 modules 目录下建立 com/mysql/main 文件夹，且把 mysql 驱动和 module.xml 文件放在 main 文件夹中。module.xml 内容如下：
 
<?xml version=”1.0″ encoding=”UTF-8″?>
 
<module xmlns=”urn:jboss:module:1.1″ name=”com.mysql”>
 
<resources>
 
<resource-root path=”mysql-connector-java-5.1.15.jar”/>
 
</resources>
 
<dependencies>
 
<module name=”javax.api”/>
 
</dependencies>
 
</module>
 
需要注意的是 name 应与建立的文件夹同名且 module.xml 文件的开头不能有空格，否则会产生“New missing/unsatisfied dependencies”错误。
 
2.2.2          注册 JDBC 驱动
 
2.2.2.1    作为模块的 JDBC 驱动注册
 
<datasource jndi-name=”java:/YourDatasourceName” pool-name=”YourDatasourceName”>
 
<connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
 
<driver> mysql-connector-java-5.1.15.jar </driver>
 
<transaction-isolation> TRANSACTION_READ_COMMITTED </transaction-isolation>
 
<pool>
 
<min-pool-size>100</min-pool-size>
 
<max-pool-size>200</max-pool-size>
 
</pool>
 
<security>
 
<user-name> USERID </user-name>
 
<password> PASSWORD</password>
 
</security>
 
<statement>
 
<prepared-statement-cache-size>100</prepared-statement-cache-size>
 
<share-prepared-statements/>
 
</statement>
 
</datasource>
 
2.2.2.2    作为部署的 JDBC 驱动注册
 
<datasource jndi-name=”java:/MySqlDS” pool-name=”MySqlDS” enabled=”true” use-java-context=”true”>
 
<connection-url>jdbc:mysql://localhost:3306/gg</connection-url>
 
<driver>mysql</driver>
 
<pool>
 
  <min-pool-size>20</min-pool-size>
 
  <max-pool-size>20</max-pool-size>
 
  <prefill>true</prefill>
 
 </pool>
 
<security>
 
    <user-name>root</user-name>
 
    <password>111</password>
 
</security>
 
<driver name=”mysql” module=”com.mysql”>
 
  <driver-class>com.mysql.jdbc.Driver</driver-class>
 
</driver>
 
</datasources>

2.3    JNDI

2.3.1 JNDI 命名规则

jboss7 使用了更为严格的 JNDI 命名规则，其基本规则如下：

（1）相对命名如“ExampleDS”或“jdbc/ExampleDS”应该修改为相对于具体环境，如“java:comp/env”,“java:jboss/env”，“java:module/env”等。

（2）绝对命名如“/jdbc/ExampleDS”应该修改为相对命名如“java:jboss/root”。

（3）如“java:/jdbc/ExampleDS”的绝对命名也应如（2）修改。

（4）“java:jboss”命名在整个 jboss 服务器中时共享的。

（5）任何以“java:”开头的命名必须结合“comp”，“module”，“app”，“global”，“jboss”中的一个，否则会报错。

2.3.2 Local JNDI

如在 HelloWorldEar 包中有 HelloWorldEJB，在 HelloWorldEJB 中有 HelloWorld bean 实现了 HelloWorldRemote 接口，则部署时 HelloWorld 绑定的 JNDI 为以下几个：
 
java:global/HelloWorldEar/HelloWorldEJB/HelloWorld!com.ejb.HelloWorldRemote
 
java:app/HelloWorldEJB/HelloWorld!com.ejb.HelloWorldRemote
 
java:module/HelloWorld!com.ejb.HelloWorldRemote
 
java:jboss/exported/HelloWorldEar/HelloWorldEJB/HelloWorld!com.ejb.HelloWorldRemote
 
java:global/HelloWorldEar/HelloWorldEJB/HelloWorld
 
java:app/HelloWorldEJB/HelloWorld
 
java:module/HelloWorld
 
2.3.3 remote JNDI
 
在 jboss5 中默认 ejb 的 JNDI 名称为：
 
      本地接口：EAR-FILE-BASE-NAME/EJB-CLASS-NAME/local
 
      远程接口：EAR-FILE-BASE-NAME/EJB-CLASS-NAME/remote
 
如果 ejb 只是在单独的 jar 包中，则不需要 EAR-FILE-BASE-NAME。而在 jboss7 中 remote ejb 的 JNDI 命名规则如下：
 
      ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>，如果是有状态 bean，则还需加上？stateful。
 
其中 app-name 指的是 ear 包的名称
 
      module-name 指的是其所在的 jar 包的名称
 
      distinct-name 指的是起的别名
 
      bean-name 指的是该 bean 的名字
 
      fully-qualified-classname-of-the-remote-interface 指的是其实现的接口的名字，要加上完整的包名。
 
2.3.4 绑定全局 JNDI
 
直接修改 standalone.xml 或者 domain.xml 文件，格式如下所示：
 
<subsystem xmlns=”urn:jboss:domain:naming:1.1″/>
 
<bindings>
 
          <lookup name=”AdminEjb/local” lookup=”ejb:/admin_ejb/AdminEjb!com.mipt.admin.ifc.AdminIfc”/>
 
</bindings>
 
3.        可能会遇到的问题
 
3.1ejb JNDI
 
由于 jboss7 与 jboss5JNDI 命名方式的差别很大，若在原有项目中大量使用了 JNDI，则在迁移时要进行更改或绑定，将是一项庞大的工程。
 
3.2 配置文件无法解析
 
在添加数据源或其他需要修改 standalone.xml 或 domain.xml 配置文件后，重新启动服务器会报无法解析配置文件的错误，可以通过 jboss-home/bin/jboss-cli.bat 来修该配置文件。以下为添加一个数据源的格式：
 
[standalone@localhost:9999 /] /subsystem=datasources:installed-drivers-list
 
{

“outcome” => “success”,

“result” => [{

“driver-name” => “h2”,

“deployment-name” => undefined,

“driver-module-name” => “com.h2database.h2”,
 
“module-slot” => “main”,

“driver-xa-datasource-class-name” => “org.h2.jdbcx.JdbcDataSource”,
 
“driver-class-name” => “org.h2.Driver”,
 
“driver-major-version” => 1,

“driver-minor-version” => 2,

“jdbc-compliant” => true

}]

3.3 ClassNotFoundException  ClassCastException
 
出现上述问题则是模块之间缺少依赖关系，导致找不到相应的类。
 
总结
 
在把项目从 jboss5 迁移到 jboss7 上时，上述 3 个步骤能解决大部分的问题

1.        Jboss7 新特性
 
1.1 构建在 Modular Service Container 上，充分地利用了多核处理器的能力，并发、按需启动服务，启动速度更快、占用内存更小。
 
1.2 全面兼容 Java EE6
 
1.3 支持 JDK6/7
 
1.4 统一的配置和管理
 
1.5 兼容 OSGI 4.2，支持 OSGI 和 Java EE 组件模型集成。
 
1.6 容易测试：利用 Arquillian 测试平台—一种集成测试组件模型，更易于测试，改变 - 编译 - 测试的周期更短。
 
1.7 两种模式
 
Standalone 模式（使用 standalone.bat 启动）相当于以前的 3、4、5、6 版本。配置文件、发布内容等放在 standalone 目录下。
 
Domain 模式（使用 domain.bat 启动）是 Jboss7 的一个新特征，可以在一个控制点管理多个服务器。
 
1.8 类加载
 
类加载基于 Jboss Module，取代了层次类加载环境，避免了当类存在多个版本时，导致类加载错误。由于类加载是基于模块的，必须显示的定义模块依赖。部署也是模块化的，如果没有显示的定义类依赖则不能访问应用服务器 jar 中的类。
 
2.        迁移步骤
 
在 Jboss7 部署项目与在 jboss5 上有很大区别，最主要原因是由于类的加载模式改变了。Jboss5 部署相对简单，只需将相应的包部署到 lib 和 deploy 目录即可，类加载器会按层次自动加载，不用配置依赖关系。而 jboss7 完全不一样，jboss7 是按模块化加载，不同模块由不同类加载器加载，其他模块的 jar 包，对其是不可见的，这时需要手动配置包之间依赖关系，否则会报 ClassNotFoundException 等错误。另外对于数据源和 JNDI 的配置也发生了变化，所以把项目从 Jboss5 往 Jboss7 迁移时可以大概分为下述 3 个步骤：
 
2.1    依赖关系的配置
 
在 Jboss7 中，模块之间的依赖关系分为隐式依赖和显式依赖。
 
2.1.1 隐式依赖
 
尽管 Jboss7 中模块默认是隔离的，在部署过程中，一些由应用服务器定义的模块依赖会自动装配。例如，如部署一个 Java EE 应用，将自动添加 Java EE API 依赖，这也称为隐式模块依赖。
 
2.1.2 显式依赖
 
对于显式依赖，必须在 MANIFEST.MF 文件的“Dependencies:”或“Class-Path:”项或在 Jboss7 特有的部署文件 jboss-deployment-structure.xml 中显式定义。对于已有的项目，手动去查找各个模块之间的依赖关系是费时又费力的，可以通过 Tattletale 工具来分析，在分析报告的 OUTPUT_DIRECTORY/index.html 文件中点击 ”JBoss A7″ 则可以得到部分依赖关系，另外的依赖关系可以在“Depends On”中得到。
 
在 Jboss7 中类的加载优先级（从高到低）：
 
（1）系统依赖 - 服务器自动加载的模块依赖，包括 Java EE api。
 
（2）用户依赖 - 在 jboss-deployment-structure.xml（在 ear 的 META-INF 内，war 的 META-INF 或 WEB-INF 内）或 Dependencies: 项内配置的依赖。
 
（3）本地资源 - 发布目录下的类文件，如 war 包下的 WEB-INF/classes 或 WEB-INF/lib。
 
（4）部署间依赖 - 在 ear 内的其他部署依赖。包括 ear lib 目录内的类，或其他 ejb 包内的类。
 
在部署时，War 包被认为是一个单独的模块，WEB-INF/lib 和 WEB-INF/classes 内的类是相同的，都由同一类加载器加载。Ear 包是多模块的部署。这意味着不是 ear 内的所有类都能访问 ear 内所有其他类，除非指定明确的依赖。默认情况下，EAR/lib 目录是一个单独的模块，每个 WAR 或 EJB jar 是一个单独的模块。子部署 (war 和 ejb-jar) 总是依赖父模块，可以访问 EAR/lib 内的类，然而它们彼此间不总是有自动依赖。可以通过修改如下配置控制这个行为：
 
<subsystem xmlns=”urn:jboss:domain:ee:1.0″ >
 
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
 
</subsystem>
 
ear-subdeployments-isolated 默认值为 false，允许子部署访问其他子部署的类。在一个 Ear 包中，war 可以访问 jar 包里的类，jar 包之间也可以相互访问，但是 jar 包不能访问 war 包中的类，不管 ear-subdeployments-isolated 的值为 true 还是 false。
 
2.1.3 全局模块
 
可以把一些模块设置为全局模块，则所有的部署都可以访问该模块，在做项目迁移时，可以使用这种方法来解决模块依赖问题。格式如下:
 
<subsystem xmlns=”urn:jboss:domain:ee:1.0″/>
 
      <global-modules>
 
              <module name=”org.apache.log4j”/>
 
      </global-modules>
 
2.2    数据源配置
 
在 Jboss5 中，数据源的配置文件为 *-ds.xml 文件，该文件放在服务器的 deploy 目录下，其相应的 JDBC 驱动则放在服务器的 lib 目录或应用程序的 WEB-INF/lib 目录下。而在 Jboss7 中这些都不需要，配置文件为 Jboss7_home/standalone/configuration/standalone.xml 或者是 Jboss7_home/domain/configuration/domaion.xml。可以使用 IronJacamar 工具把原来的 *-ds.xml 文件转变为 Jboss7 中所需要的格式。
 
2.2.1          安装 JDBC 驱动
 
安装 JDBC 驱动分为两种方式：（1）作为一个部署（推荐的做法）（2）作为一个模块
 
2.2.1.1    作为一个部署
 
直接把 JDBC 驱动作为一个普通的 jar 包放在 deployment 目录下，该 JDBC 驱动应该是一个兼容 JDBC4（Jdbc 4 兼容的 driver 在 jar 包内含有 META-INF/services/java.sql.Driver 文件，其中指定了驱动类名称。）的驱动。若 JDBC 驱动包含不止一个 jar 包，则应作为一个模块来部署。
 
2.2.1.2    作为一个模块
 
需要在 modules 目录下创建一个目录结构，其内包含驱动 jar 包和 module.xml 文件。下面以安装 mysql 驱动为例，首先在 modules 目录下建立 com/mysql/main 文件夹，且把 mysql 驱动和 module.xml 文件放在 main 文件夹中。module.xml 内容如下：
 
<?xml version=”1.0″ encoding=”UTF-8″?>
 
<module xmlns=”urn:jboss:module:1.1″ name=”com.mysql”>
 
<resources>
 
<resource-root path=”mysql-connector-java-5.1.15.jar”/>
 
</resources>
 
<dependencies>
 
<module name=”javax.api”/>
 
</dependencies>
 
</module>
 
需要注意的是 name 应与建立的文件夹同名且 module.xml 文件的开头不能有空格，否则会产生“New missing/unsatisfied dependencies”错误。
 
2.2.2          注册 JDBC 驱动
 
2.2.2.1    作为模块的 JDBC 驱动注册
 
<datasource jndi-name=”java:/YourDatasourceName” pool-name=”YourDatasourceName”>
 
<connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
 
<driver> mysql-connector-java-5.1.15.jar </driver>
 
<transaction-isolation> TRANSACTION_READ_COMMITTED </transaction-isolation>
 
<pool>
 
<min-pool-size>100</min-pool-size>
 
<max-pool-size>200</max-pool-size>
 
</pool>
 
<security>
 
<user-name> USERID </user-name>
 
<password> PASSWORD</password>
 
</security>
 
<statement>
 
<prepared-statement-cache-size>100</prepared-statement-cache-size>
 
<share-prepared-statements/>
 
</statement>
 
</datasource>
 
2.2.2.2    作为部署的 JDBC 驱动注册
 
<datasource jndi-name=”java:/MySqlDS” pool-name=”MySqlDS” enabled=”true” use-java-context=”true”>
 
<connection-url>jdbc:mysql://localhost:3306/gg</connection-url>
 
<driver>mysql</driver>
 
<pool>
 
  <min-pool-size>20</min-pool-size>
 
  <max-pool-size>20</max-pool-size>
 
  <prefill>true</prefill>
 
 </pool>
 
<security>
 
    <user-name>root</user-name>
 
    <password>111</password>
 
</security>
 
<driver name=”mysql” module=”com.mysql”>
 
  <driver-class>com.mysql.jdbc.Driver</driver-class>
 
</driver>
 
</datasources>