《如何在was中解决jar包冲突》由会员分享，可在线阅读，更多相关《如何在was中解决jar包冲突（15页珍藏版）》请在金锄头文库上搜索。
1、如何在was中解决jar包冲突大型的基于 WebSphere 的项目开发中，同一个 WebSphere Application Server（以下简称 WAS）上会部署多个应用程序，而这多个应用程序必然会共用一些 jar 包，包括第三方提供的工具和项目内部的公共 jar 等。把这些共用的 jar 包提取出来在多个应用程序之间共享，不仅可以统一对这些 jar 包进行维护，同时也提高了 WAS 的性能。但是随着应用的不断扩大，新的应用程序的不断增加，新的应用程序会希望使用一些更高版本的共享 jar 包，而由于系统运行维护的需要，老的应用程序仍然希望用老版本的共享 jar 包，这样就必然造成了共享
2、jar 包的版本冲突。jar 包版本冲突问题是在大型应用项目的开发中经常遇到的问题，本文试图从 WebSphere 的类加载器入手，讨论几种在不同情况下解决 jar 包冲突问题的办法。WebSphere 中类加载器介绍Jar 包冲突实际上是应用程序运行时不能找到真正所需要的类，而影响类的查找和加载的是 JVM 以及 WebSphere 中的类加载器（class loader），为此，我们首先介绍一下 WebSphere 中的类加载器以及一些相关的概念。WebSphere 中类加载器层次结构Java 应用程序运行时，在 class 执行和被访问之前，它必须通过类加载器加载使之有效，类加载器是 J
3、VM 代码的一部分，负责在 JVM 虚拟机中查找和加载所有的 Java 类和本地的 lib 库。类加载器的不同配置影响到应用程序部署到应用程序服务器上运行时的行为。JVM 和 WebSphere 应用程序服务器提供了多种不同的类加载器配置， 形成一个具有父子关系的分层结构。WebSphere 中类加载器的层次结构图 1 所示：图 1：WebSphere 中类加载器的层次结构如上图所示，WebSphere 中类加载器被组织成一个自上而下的层次结构，最上层是系统的运行环境 JVM，最下层是具体的应用程序，上下层之间形成父子关系。 JVM Class loader：位于整个层次结构的最上层，它是整个
4、类加载器层次结构的根，因此它没有父类加载器。这个类加载器负责加载 JVM 类， JVM 扩展类，以及定义在 classpath 环境变量上的所有的 Java 类。 WebSphere Extensions Class loader：WebSphere 扩展类加载器 , 它将加载 WebSphere 的一些 runtime 类，资源适配器类等。 WebSphere lib/app Class loader：WebSphere 服务器类加载器，它将加载 WebSphere 安装目录下 $(WAS_HOME)/lib/app 路径上的类。 在 WAS v4 版本中，WAS 使用这个路径在所有的应用程
5、序之间共享 jar 包。从 WAS v5 开始， 共享库功能提供了一种更好的方式，因此，这个类加载器主要用于一些原有的系统的兼容。 WebSphere server Class loader：WebSphere 应用服务器类加载器。 它定义在这个服务器上的所有的应用程序之间共享的类。WAS v5 中有了共享库的概念之后，可以为应用服务器定义多个与共享库相关联的类加载器，他们按照定义的先后顺序形成父子关系。 Application Module Class Loader：应用程序类加载器，位于层次结构的最后一层，用于加载 J2EE 应用程序。根据应用程序的类加载策略的不同，还可以为 Web 模块
6、定义自己的类加载器。关于 WebSphere 的类加载器的层次结构，以下的几点说明可能更有助于进一步的理解类的查找和加载过程： 每个类加载器负责在自身定义的类路径上进行查找和加载类。 一个子类加载器能够委托它的父类加载器查找和加载类，一个加载类的请求会从子类加载器发送到父类加载器，但是从来不会从父类加载器发送到子类加载器。 一旦一个类被成功加载，JVM 会缓存这个类直至其生命周期结束，并把它和相应的类加载器关联在一起，这意味着不同的类加载器可以加载相同名字的类。 如果一个加载的类依赖于另一个或一些类，那么这些被依赖的类必须存在于这个类的类加载器查找路径上，或者父类加载器查找路径上。 如果一个类
7、加载器以及它所有的父类加载器都无法找到所需的类，系统就会抛出 ClassNotFoundExecption 异常或者 NoClassDefFoundError 的错误。类加载器的委托模式类加载器有一个重要的属性：委托模式（Delegation Mode，有时也称为加载方式：Classloader mode）。委托模式决定了类加载器在查找一个类的时候， 是先查找类加载器自身指定的类路径还是先查找父类加载器上的类路径。类加载器的委托模式有两个取值： Parent_First：在加载类的时候，在从类加载器自身的类路径上查找加载类之前，首先尝试在父类加载器的类路径上查找和加载类。 Parent_Las
8、t：在加载类的时候，首先尝试从自己的类路径上查找加载类，在找不到的情况下，再尝试父类加载器类路径。有了委托模式的概念，我们可以更加灵活的配置在类加载器的层次结构中类的加载和查找方式。表 1 中给出了在 WebSphere 的类加载器层次结构中各个类加载器的委托模式的定义，并给出了不同的类加载器内类的生命周期。注意：在上表中，JVM Class loader 因为在类加载器的最顶层，它没有父类加载器，因此其委托模式为 N/A，WebSphere Extensions Class loader和WebSphere lib/app Class loader的委托模式固定为表中的取值，不可配置，其它的
9、类加载器的委托模式都是可以配置的。WebSphere 中的类加载器策略WebSphere 中对类加载器有一些相关的配置，称为类加载器策略（class loader policy）。类加载器策略指类加载器的独立策略（class loader isolation policy）, 通过类加载器策略设置，我们可以为 WAS 和应用程序的类加载器进行独立定义。每个 WAS 可以配置自己的应用程序类加载器策略，WAS 中的每个应用程序也可以配置自己的 Web 模块类加载器策略，下面我们对这两种策略分别介绍。1 应用服务器（WAS）配置：应用程序类加载器策略应用服务器对应用程序类加载器策略有两种配置： S
10、ingle：整个应用服务器上的所有应用程序使用同一个类加载器。在这种配置下，每个应用程序不再有自己的类加载器。 Multiple：应用服务器上的每个应用程序使用自己的类加载器。2 应用程序配置：Web 模块类加载器策略应用程序中对 Web 模块类加载器有两种配置： Application：整个应用程序内的所有的实用程序 jar 包和 Web 模块使用同一个类加载器。 Module：应用程序内的每个 Web 模块使用自己的类加载器。应用程序的类加载器仍然存在，负责加载应用程序中 Web 模块以外的其它类，包括所有的实用程序 jar 包。从上面的定义可以看出，不同的类加载器策略的配置下，类加载器的
11、层次结构上的某些类加载器可能不存在。比如在应用程序服务器的应用程序类加载器策略定义为 single 的情况下，应用程序的类加载器将不存在，同一个应用服务器上的所有应用程序将共用同一个类加载器，这也就意味着不同的应用程序之间的类是共享的，应用程序间不能存在同名的类。在 WebSphere 中解决 jar 包冲突Jar 包冲突问题实际上就是应用程序希望用某一个确定版本的 jar 包中的类，但是类加载器却找到并加载了另外一个版本的 jar 包中的类。在上一部分介绍了 WebSphere 中类加载器的基本概念和相关配置之后，我们来看如何在 WebSphere 中解决 jar 包冲突。在 WAS v5
12、版本之前，使用共享 jar 包的方式是将 jar 包放在 $(WAS_HOME)/lib/app 路径下，从上一部分中，我们可以看到，这个路径正是WebSphere lib/app Class loader 类加载器的类查找路径，WebSphere 会查找这个路径以取得相应得 jar 包中的 Java 类，从而做到在 WebSphere ND 上的多个应用程序之间共享 jar 包的目的。但是这样做的一个缺点就是这些共享 jar 包暴露给 WebSphere ND 上所有的应用程序，对于那些希望使用 jar 包其它版本的应用程序，这些 jar 包也同样存在在了它们的类加载器类路径上，因此，就不可
13、避免的会造成版本的冲突。在 WAS v5 版本及之后，增加了共享库（shared library）的概念，推荐的在多个应用程序间共享 jar 包并避免 jar 包冲突的方式是使用共享库。具体分析引起 jar 包冲突的情况，主要有三种： 多个应用程序间 jar 包冲突：多个应用程序间由于使用了共享 jar 包的不同版本而造成 jar 包版本冲突。 应用程序中多个 Web 模块间 jar 包冲突：同一个应用程序内部，不同的 Web 模块间同时使用一个 jar 包的不同版本而造成 jar 包版本冲突。 应用程序中同一个 Web 模块内 jar 包冲突：同一个应用程序内部，同一个 Web 模块内，由于
14、需要同时使用同一个 jar 包的两个版本而造成的 jar 包冲突本部分根据这三种 jar 包冲突的情况，讨论三种解决 jar 包冲突的办法，并具体讨论三种解决办法的实现步骤和适用情况： 共享库方式解决 jar 包冲突：主要解决应用程序间的 jar 包冲突问题 打包到 Web 模块中解决 jar 包冲突：主要解决应用程序中多个 Web 模块间 jar 包冲突问题 命令行运行方式解决 jar 包冲突：主要解决应用程序中同一个 Web 模块内 jar 包冲突问题共享库方式解决 jar 包冲突在 WAS v5 中，提供了一种很好的机制，使得 jar 包只存在于需要这个 jar 包的应用程序的类加载器的
15、路径上，而其它的应用程序不受它的任何影响，这就是共享库（Shared library）。共享库可以用在应用服务器级别和应用程序级别，使用应用程序级别的共享库，其好处就是在不同的应用程序之间使用共享 jar 包的不同版本。我们可以为一些通用 jar 包的每个不同版本定义成不同的共享库，应用程序希望使用哪个版本，就把这个版本的共享库放到应用程序的类加载器的类路径上，这种方式有效的解决了应用程序之间 jar 包冲突的问题。下面举例介绍定义和使用共享库的具体方法，本例中，假设存在 xerces.jar 包版本冲突。1 定义共享库系统管理员可以在 WebSphere 的 Admin console 中定
16、义共享库，可以分别在 Cell、Node 以及 server 的级别上定义。 步骤一 : 进入 Admin console，选择 Environment Shared Library new。如图 2 所示：图 2：WebSphere Admin Console 中进入共享库页面 步骤二： 给出共享库的名字，并指定共享的文件和目录。多个不同的文件 / 目录之间通过Enter键分隔，且不能有路径分隔符，如:和;等。如图 3 所示：图 3：WebSphere Admin Console 中添加共享库 步骤三：点击 Apply 或者 OK 之后，就添加了一个名字为 Xerces V2.0 的共享库。记住添加完成后一定要在 admin console 保存配
