如何在 WebSphere 中解决 jar 包冲突（转载）
大型的基于 WebSphere 的项目开发中，同一个 WebSphere Application Server（以下简称 WAS）上会部署多个应用程序，而这多个应用程序必然会共用一些 jar 包，包括第三方提供的工具和项目内部的公共 jar 等。把这些共用的 jar 包提取出来在多个应用程序之间共享，不仅可以统一对这些 jar 包进行维护，同时也提高了 WAS 的性能。但是随着应用的不断扩大，新的应用程序的不断增加，新的应用程序会希望使用一些更高版本的共享 jar 包，而由于系统运行维护的需要，老的应用程序仍然希望用老版本的共享 jar 包，这样就必然造成了共享 jar 包的版本冲突。jar 包版本冲突问题是在大型应用项目的开发中经常遇到的问题，本文试图从 WebSphere 的类加载器入手，讨论几种在不同情况下解决 jar 包冲突问题的办法。
WebSphere 中类加载器介绍
Jar 包冲突实际上是应用程序运行时不能找到真正所需要的类，而影响类的查找和加载的是 JVM 以及 WebSphere 中的类加载器（class loader），为此，我们首先介绍一下 WebSphere 中的类加载器以及一些相关的概念。
WebSphere 中类加载器层次结构
Java 应用程序运行时，在 class 执行和被访问之前，它必须通过类加载器加载使之有效，类加载器是 JVM 代码的一部分，负责在 JVM 虚拟机中查找和加载所有的 Java 类和本地的 lib 库。类加载器的不同配置影响到应用程序部署到应用程序服务器上运行时的行为。JVM 和 WebSphere 应用程序服务器提供了多种不同的类加载器配置， 形成一个具有父子关系的分层结构。WebSphere 中类加载器的层次结构图 1 所示：
图 1：WebSphere 中类加载器的层次结构
?
如上图所示，WebSphere 中类加载器被组织成一个自上而下的层次结构，最上层是系统的运行环境 JVM，最下层是具体的应用程序，上下层之间形成父子关系。
关于 WebSphere 的类加载器的层次结构，以下的几点说明可能更有助于进一步的理解类的查找和加载过程：
类加载器的委托模式
类加载器有一个重要的属性：委托模式（Delegation Mode，有时也称为加载方式：Classloader mode）。委托模式决定了类加载器在查找一个类的时候， 是先查找类加载器自身指定的类路径还是先查找父类加载器上的类路径。
类加载器的委托模式有两个取值：
有了委托模式的概念，我们可以更加灵活的配置在类加载器的层次结构中类的加载和查找方式。表 1 中给出了在 WebSphere 的类加载器层次结构中各个类加载器的委托模式的定义，并给出了不同的类加载器内类的生命周期。
?
注意：在上表中，"JVM Class loader" 因为在类加载器的最顶层，它没有父类加载器，因此其委托模式为 N/A，"WebSphere Extensions Class loader"和"WebSphere lib/app Class loader"的委托模式固定为表中的取值，不可配置，其它的类加载器的委托模式都是可以配置的。
WebSphere 中的类加载器策略
WebSphere 中对类加载器有一些相关的配置，称为类加载器策略（class loader policy）。类加载器策略指类加载器的独立策略（class loader isolation policy）, 通过类加载器策略设置，我们可以为 WAS 和应用程序的类加载器进行独立定义。
每个 WAS 可以配置自己的应用程序类加载器策略，WAS 中的每个应用程序也可以配置自己的 Web 模块类加载器策略，下面我们对这两种策略分别介绍。
1 ．应用服务器（WAS）配置：应用程序类加载器策略
应用服务器对应用程序类加载器策略有两种配置：
2 ．应用程序配置：Web 模块类加载器策略
应用程序中对 Web 模块类加载器有两种配置：
从上面的定义可以看出，不同的类加载器策略的配置下，类加载器的层次结构上的某些类加载器可能不存在。比如在应用程序服务器的应用程序类加载器策略定义为 single 的情况下，应用程序的类加载器将不存在，同一个应用服务器上的所有应用程序将共用同一个类加载器，这也就意味着不同的应用程序之间的类是共享的，应用程序间不能存在同名的类。
?回页首
在 WebSphere 中解决 jar 包冲突
Jar 包冲突问题实际上就是应用程序希望用某一个确定版本的 jar 包中的类，但是类加载器却找到并加载了另外一个版本的 jar 包中的类。在上一部分介绍了 WebSphere 中类加载器的基本概念和相关配置之后，我们来看如何在 WebSphere 中解决 jar 包冲突。
在 WAS v5 版本之前，使用共享 jar 包的方式是将 jar 包放在 $(WAS_HOME)/lib/app 路径下，从上一部分中，我们可以看到，这个路径正是"WebSphere lib/app Class loader" 类加载器的类查找路径，WebSphere 会查找这个路径以取得相应得 jar 包中的 Java 类，从而做到在 WebSphere ND 上的多个应用程序之间共享 jar 包的目的。但是这样做的一个缺点就是这些共享 jar 包暴露给 WebSphere ND 上所有的应用程序，对于那些希望使用 jar 包其它版本的应用程序，这些 jar 包也同样存在在了它们的类加载器类路径上，因此，就不可避免的会造成版本的冲突。在 WAS v5 版本及之后，增加了共享库（shared library）的概念，推荐的在多个应用程序间共享 jar 包并避免 jar 包冲突的方式是使用共享库。
具体分析引起 jar 包冲突的情况，主要有三种：
本部分根据这三种 jar 包冲突的情况，讨论三种解决 jar 包冲突的办法，并具体讨论三种解决办法的实现步骤和适用情况：
共享库方式解决 jar 包冲突
在 WAS v5 中，提供了一种很好的机制，使得 jar 包只存在于需要这个 jar 包的应用程序的类加载器的路径上，而其它的应用程序不受它的任何影响，这就是共享库（Shared library）。共享库可以用在应用服务器级别和应用程序级别，使用应用程序级别的共享库，其好处就是在不同的应用程序之间使用共享 jar 包的不同版本。我们可以为一些通用 jar 包的每个不同版本定义成不同的共享库，应用程序希望使用哪个版本，就把这个版本的共享库放到应用程序的类加载器的类路径上，这种方式有效的解决了应用程序之间 jar 包冲突的问题。
下面举例介绍定义和使用共享库的具体方法，本例中，假设存在 xerces.jar 包版本冲突。
1 ． 定义共享库
系统管理员可以在 WebSphere 的 Admin console 中定义共享库，可以分别在 Cell、Node 以及 server 的级别上定义。
步骤一 : 进入 Admin console，选择 Environment > Shared Library > new。如图 2 所示：
步骤二： 给出共享库的名字，并指定共享的文件和目录。多个不同的文件 / 目录之间通过"Enter"键分隔，且不能有路径分隔符，如":"和";"等。如图 3 所示：
步骤三：点击 Apply 或者 OK 之后，就添加了一个名字为 Xerces V2.0 的共享库。记住添加完成后一定要在 admin console 保存配置。如图 4 所示：
2 ．安装应用程序
进入 Admin console，选择 Applications > Install New Application 安装应用程序。请参照 IBM WebSphere 的 Admin console 使用手册进行安装新的应用程序，此处不再详细介绍。
3 ．将共享库关联到应用程序
步骤一：进入 Admin console，选择 Applications > Enterprise applications ，并选择需要使用共享库的应用程序。注意：因为要改变应用程序的设置，所以如果应用程序已经运行，需要先停掉应用程序。如图 5 所示：
步骤二 : 点击应用程序，进入后，选择 Libraries。如图 6 所示：
步骤三 : 点击 Add，为应用程序添加共享库。如图 7 所示：
步骤四 : 从下拉列表中选择所需要的共享库，点击 OK。如图 8 所示：
这样，Xerces V2.0 共享库定义的 xerces 版本就存在于了应用程序类加载器的类加载路径上。注意，在添加完成后要保存服务器的设置。
4 ．设置应用程序的类加载器的委托模式为 Parent_Last
为了进一步防止共享库定义的 jar 包的其它版本已经存在于 JVM 或者 WebSphere 的类加载器路径上，还需要设置应用程序的类加载器的委托方式为 Parent_Last。
步骤一：进入 Admin console，选择 Applications > Enterprise applications > ，选择需要配置的应用程序。如图 9 所示：
步骤二：点击进入应用程序，设置类加载器的委托模式为 Parent_Last。注意：在配置完成后，要保存配置，最后启动应用程序。如图 10 所示：
通过上面的配置，即使 xerces 的其它版本已经存在于系统中，应用程序在运行时，其类加载器也会首先查找并加载指定的共享库中的 xerces 版本。这样我们就通过使用共享库的方式，解决了 jar 包版本冲突问题。
打包到 Web 模块中解决 jar 包冲突
共享库的方式，只是在应用程序的层次上，在多个应用程序之间解决了共享 jar 包造成的版本冲突问题，如果一个应用程序的内部，其中一个 Web 模块使用了一个 jar 包的 A 版本，而另一个 Web 模块使用这个 jar 包的 B 版本，在这种情况下造成的 jar 包冲突，共享库的方式是无法解决的，我们可以考虑将其中一个在多个应用程序间共享的 jar 包版本，比如 A 版本，定义成共享库，或者放在"WebSphere lib/app Class loader"类加载器路径上供多个应用程序使用，而将 B 版本的 jar 包打包到使用它的 Web 模块中的方式来解决冲突。
其次，目前很多在线的系统是 WAS v4 的遗留系统，其上运行的应用程序已经使用了"WebSphere lib/app Class loader"类加载器，将 jar 包放在 $(WAS_HOME)/lib/app 目录下进行共享。如果由于其中某个应用程序的升级或者新增加某个应用程序，需要使用某个共享 jar 包的其它版本，在这种情况下，为了减少对系统的影响，也可以考虑将这个共享 jar 包的新版本打包到升级（或新增）的应用程序中的方式来解决 jar 包冲突。
由于 Web 模块的 WebContent/WEB-INFO/lib 目录在应用程序 Web 模块的类加载器查找路径上，因此，我们可以把 jar 包放在这个目录下，Web 模块的类加载器将自动查找并加载这个 jar 包中的类。
步骤一：在 WSAD IE 集成开发环境中，将冲突 jar 包放在 Web 模块的 WebContent/WEB-INFO/lib 目录下。如图 11 所示：
步骤二：在 Admin console 中，将应用程序部署到 WebSphere server 上之后，进入 Applications > Enterprise Applications, 选择相应的应用程序，并确认应用程序不在运行状态 ( 参见前面章节中选择应用程序的步骤 )。点击进入应用程序，确认应用程序的类加载器的委托模式为 Parent_First, 应用程序的类加载器策略为 Module。如图 12 所示：
步骤三：在同一个页面上，选择 Web Modules，点击进入。如图 13 所示：
步骤四：点击相应的包含冲突 jar 包的 Web 模块，设置 Web 模块的类加载器的委托模式为 Parent_Last。注意：在设置完成后要保存服务器配置，并启动应用程序。如图 14 所示：
?图 14：WebSphere Admin Console 中为 Web 模块指定类加载器委托模式将冲突 jar 包打包到 Web 模块中，并设置相应 Web 模块的类加载器的委托模式为 Parent_Last，应用程序在运行过程中加载类的时候，这个 Web 模块的类加载器会首先查找 WebContent/WEB-INFO/lib 目录下的 jar 包进行类的加载；而对于其它的 Web 模块，由于其类加载器的委托模式仍然为缺省的 Parent_First，它们的类加载器仍然首先从应用程序的共享库或者 WebSphere 的共享路径上加载 jar 包中的类，从而解决了 jar 包冲突的问题。
命令行运行方式解决 jar 包冲突
不论是设置共享库，还是将冲突 jar 包打包到应用程序中，其解决的问题都是在应用程序的一个 Web 模块中只使用了冲突 jar 包的一个版本的情况。我们在开发中曾经遇到过这样的情况：应用程序的 Web 模块中已经使用了 1.4 版本的 xerces.jar，由于 Web 功能的扩展，在这个模块中又引入一个新的第三方工具，而这个第三方工具需要使用 2.0 版本的 xerces.jar 才能正常工作，这种情况下的 jar 包冲突如何解决呢？
在前面类加载器的部分已经介绍过，每个应用程序的一个 Web 模块最多只能有一个类加载器，而 Web 模块的类加载器中加载的类的生命周期为整个应用程序的运行期，也就是说，Web 模块加载器不可能同时加载一个类的两个版本，同时，Web 模块的类加载器的委托模式也是在应用程序运行前设置的，在应用程序运行期内无法改变的，因此，上面描述的在一个 Web 模块中同时使用两个版本的 jar 包的问题，象前两种方法那样配置运行在一个 JVM 内的类加载器的设置的方法是无法解决的。
唯一的解决办法就是在应用程序运行的 JVM 外，启动另外一个 JVM 来运行调用冲突 jar 包的代码，因为两个不同的 JVM 可以加载各自的类，从而解决 jar 包冲突问题。
这种情况下，原来使用 jar 包的老版本的方式（包括 jar 包放置路径，共享库设置方式，类加载器的委托模式等）不变，将对 jar 包新版本的调用通过命令行运行方式实现。具体做法是：将对 jar 包新版本内功能的调用，封装到一个可以单独运行的类中，在 Web 模块中以命令行方式运行这个类。同时把这个类以及 jar 包的新版本放在任意一个 was 可访问的路径上（比如 /usr/WebSphere），在命令行的 classpath 参数中包含这个路径（比如 /usr/WebSphere）。
下面通过举例说明命令行运行方式的编程过程，在本例中，假设 TestEar 应用程序的 Web 模块 TestWar 中，已经使用了 conflict_v1.jar，由于新添功能需要使用 conflict_v2.jar 中的 exampleCall() 功能。
冲突 jar 包 conflict_v2.jar 提供的功能：
代码 1：冲突 jar 包 conflict_v2.jar 功能
代码 4：在应用程序中通过命令行方式运行 WorkAround
命令行运行方式通过启动另外一个 JVM 的方式运行冲突代码，在一个不同的 JVM 中加载冲突的类，从而解决了 jar 包冲突问题。
但是命令行运行方式毕竟不是一个很好的方式，它存在以下的弊端：
因此，命令行方式只适用于一些极为特殊的情况下解决 jar 包冲突问题。
?回页首
结论
本文对基于 WebSphere 的大型项目开发中遇到的 jar 包冲突问题，结合 WebSphere 中类加载器的概念，给出了三种解决办法以及相应的操作步骤和实现代码，并分析了各种方式所适用的具体情况。
项目开发过程中的 jar 包冲突，主要存在以下三种情况：
通过对类加载器的分析我们知道，解决 jar 包冲突问题的根本在于合理配置类加载器。在深入理解 WebSphere 中类加载器的层次结构的基础上，我们给出了"共享库解决 jar 包冲突"以及"打包到 Web 模块中解决 jar 包冲突"的办法，通过合理地配置 WebSphere 中类加载器及其委托模式，可以解决大多数的 jar 包冲突问题。但是由于这个层次结构中类加载器只配置到 Web 模块，因此，对于 Web 模块内部的 jar 包冲突问题，类加载器的配置是无法解决的，为此我们给出了"命令行运行方式解决 jar 包冲突"的办法。
表 2 中列出了在不同的 WAS 版本下，三种解决 jar 包冲突问题的办法所适用的 jar 包冲突情况。
表 2：Jar 包冲突解决办法适用的 jar 包冲突情况总结
原载文章：http://www.ibm.com/developerworks/cn/websphere/library/techarticles/haoaili/0512/
?
