Jar包冲突问题是在大型Java软件开发中经常遇到的问题，系统开发人员经常会为解决类似的问题耗费大量的时间进行调试和测试，本文根据各种际情况，结合WebSphere中类加载器，讨论了几种解决 jar包冲突问题的办法，并给出了具体实现的步骤及源代码。
读者定位为具有Java和WebSphere开发经验的开发人员。
读者可以学习到在 WebSphere中类加载器的定义以及解决jar包冲突问题的几种办法，并可以直接使用文章中提供的Java代码，从而节省他们的开发和调试时间，提高效率。
大型的基于WebSphere的项目开发中，同一个WebSphereApplicationServer（以下简称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，最下层是具体的应用程序，上下层之间形成父子关系。
* JVM Class loader：位于整个层次结构的最上层，它是整个类加载器层次结构的根，因此它没有父类加载器。这个类加载器负责加载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使用这个路径在所有的应用程序之间共享jar包。从WAS v5开始， 共享库功能提供了一种更好的方式，因此，这个类加载器主要用于一些原有的系统的兼容。
* WebSphere “server” Class loader：WebSphere应用服务器类加载器。 它定义在这个服务器上的所有的应用程序之间共享的类。WAS v5中有了共享库的概念之后，可以为应用服务器定义多个与共享库相关联的类加载器，他们按照定义的先后顺序形成父子关系。
* Application Module Class Loader：应用程序类加载器，位于层次结构的最后一层，用于加载J2EE应用程序。根据应用程序的类加载策略的不同，还可以为Web模块定义自己的类加载器。
关于WebSphere的类加载器的层次结构，以下的几点说明可能更有助于进一步的理解类的查找和加载过程：
* 每个类加载器负责在自身定义的类路径上进行查找和加载类。
* 一个子类加载器能够委托它的父类加载器查找和加载类，一个加载类的请求会从子类加载器发送到父类加载器，但是从来不会从父类加载器发送到子类加载器。
* 一旦一个类被成功加载，JVM 会缓存这个类直至其生命周期结束，并把它和相应的类加载器关联在一起，这意味着不同的类加载器可以加载相同名字的类。
* 如果一个加载的类依赖于另一个或一些类，那么这些被依赖的类必须存在于这个类的类加载器查找路径上，或者父类加载器查找路径上。
* 如果一个类加载器以及它所有的父类加载器都无法找到所需的类，系统就会抛出ClassNotFoundExecption异常或者 NoClassDefFoundError的错误。
类加载器的委托模式
类加载器有一个重要的属性：委托模式（Delegation Mode，有时也称为加载方式：Classloader mode）。委托模式决定了类加载器在查找一个类的时候， 是先查找类加载器自身指定的类路径还是先查找父类加载器上的类路径。
类加载器的委托模式有两个取值：
* Parent_First：在加载类的时候，在从类加载器自身的类路径上查找加载类之前，首先尝试在父类加载器的类路径上查找和加载类。
* Parent_Last：在加载类的时候，首先尝试从自己的类路径上查找加载类，在找不到的情况下，再尝试父类加载器类路径。
有了委托模式的概念，我们可以更加灵活的配置在类加载器的层次结构中类的加载和查找方式。表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）配置：应用程序类加载器策略
应用服务器对应用程序类加载器策略有两种配置：
* Single：整个应用服务器上的所有应用程序使用同一个类加载器。在这种配置下，每个应用程序不再有自己的类加载器。
* Multiple：应用服务器上的每个应用程序使用自己的类加载器。
2．应用程序配置：Web模块类加载器策略
应用程序中对Web模块类加载器有两种配置：
* Application：整个应用程序内的所有的实用程序jar包和Web模块使用同一个类加载器。
* Module：应用程序内的每个Web模块使用自己的类加载器。应用程序的类加载器仍然存在，负责加载应用程序中Web模块以外的其它类，包括所有的实用程序jar包。
从上面的定义可以看出，不同的类加载器策略的配置下，类加载器的层次结构上的某些类加载器可能不存在。比如在应用程序服务器的应用程序类加载器策略定义为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包版本冲突。
* 应用程序中多个Web模块间jar包冲突：同一个应用程序内部，不同的Web模块间同时使用一个jar包的不同版本而造成jar包版本冲突。
* 应用程序中同一个Web模块内jar包冲突：同一个应用程序内部，同一个Web模块内，由于需要同时使用同一个jar包的两个版本而造成的jar包冲突
本部分根据这三种jar包冲突的情况，讨论三种解决jar包冲突的办法，并具体讨论三种解决办法的实现步骤和适用情况：
* 共享库方式解决jar包冲突：主要解决应用程序间的jar包冲突问题
* 打包到Web模块中解决jar包冲突：主要解决应用程序中多个Web模块间 jar包冲突问题
* 命令行运行方式解决jar包冲突：主要解决应用程序中同一个Web模块内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所示：
图2：WebSphere Admin Console中进入共享库页面
* 步骤二： 给出共享库的名字，并指定共享的文件和目录。多个不同的文件/目录之间通过”Enter”键分隔，且不能有路径分隔符，如”:”和”;”等。如图3所示：
图3：WebSphere Admin Console中添加共享库
* 步骤三：点击Apply或者OK之后，就添加了一个名字为Xerces V2.0的共享库。记住添加完成后一定要在admin console保存配置。如图4所示：
图4：WebSphere Admin Console中共享库列表
*
2．安装应用程序
进入Admin console，选择Applications > Install New Application 安装应用程序。请参照IBMWebSphere的Admin console使用手册进行安装新的应用程序，此处不再详细介绍。
3．将共享库关联到应用程序
* 步骤一：进入Admin console，选择Applications >Enterpriseapplications ，并选择需要使用共享库的应用程序。注意：因为要改变应用程序的设置，所以如果应用程序已经运行，需要先停掉应用程序。如图5所示：
图5：WebSphere Admin Console中选择需要配置的应用程序
* 步骤二: 点击应用程序，进入后，选择Libraries。如图6所示：
图6：WebSphere Admin Console中选择应用程序库属性
* 步骤三: 点击Add，为应用程序添加共享库。如图7所示：
图7：WebSphere Admin Console中应用程序添加库
* 步骤四: 从下拉列表中选择所需要的共享库，点击OK。如图8所示：
图8：WebSphere Admin Console中应用程序添加库页面指定所用的共享库
这样，Xerces V2.0共享库定义的xerces版本就存在于了应用程序类加载器的类加载路径上。注意，在添加完成后要保存服务器的设置。
4．设置应用程序的类加载器的委托模式为Parent_Last
为了进一步防止共享库定义的jar包的其它版本已经存在于JVM或者WebSphere的类加载器路径上，还需要设置应用程序的类加载器的委托方式为Parent_Last。
* 步骤一：进入 Admin console，选择Applications > Enterprise applications > ，选择需要配置的应用程序。如图9所示：
图9：WebSphere Admin Console中选择需要配置的应用程序
* 步骤二：点击进入应用程序，设置类加载器的委托模式为Parent_Last。注意：在配置完成后，要保存配置，最后启动应用程序。如图10所示：
图10：WebSphere Admin Console中为应用程序设置类加载器委托模式
通过上面的配置，即使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所示：
图11：WSAD IE中为Web模块添加库
* 步骤二：在Admin console中，将应用程序部署到WebSphere server上之后，进入Applications > Enterprise Applications,选择相应的应用程序，并确认应用程序不在运行状态(参见前面章节中选择应用程序的步骤)。点击进入应用程序，确认应用程序的类加载器的委托模式为Parent_First,应用程序的类加载器策略为Module。如图12所示：
图12：WebSphere Admin Console中应用程序属性配置页面
* 步骤三：在同一个页面上，选择 Web Modules，点击进入。如图13所示：
图13：WebSphere Admin Console中选择应用程序Web模块属性
* 步骤四：点击相应的包含冲突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功能
Package com.ibm.conflictublic class ConflictClass{ …….Public static String exampleCall(string param){ String rs; ……; Return rs;}……}
不存在冲突问题时的编码举例：
如果没有jar包冲突问题，则对这个功能的调用是简单的，只需要将conflict_v2.jar放在应用程序自身或者其父类加载器的查找路径上，然后在Web模块中直接调用即可，如下：
代码2：不存在冲突时的调用方式
Public String methodA(String param){ …… String rs = ConflictClass.exampleCall(param); …… Return rs;}
存在冲突后的命令行运行方式编码举例
针对jar包冲突问题，我们需要在Web模块中做如下的修改：
* 步骤一：将冲突jar包放在was可访问的路径上，比如/usr/WebSphere/conflict_v2.jar。
* 步骤二：将对包含冲突代码的调用封装到一组可单独运行的类中，它们将调用冲突jar包的功能，并将结果以系统输出的方式打印到系统标准输出上。 将这些类封装到一个单独的jar文件中，比如workAroundConflict.jar，并将其放在was可访问的路径上，比如/usr /WebSphere/workAroundConflict.jar。
Package com.ibm.test;Import com.ibm.ConflictClassublic class WorkAround{Public static void main(String[] args){ String param1=args[0]; String returnStr=ConflictClass.exampleCall (); System.out.println(“<RTStr>”+returnStr+”</RTStr>”); Return;}}
代码3：将对冲突代码的调用写入一个单独的类 WorkAround
* 步骤三：在Web模块中通过命令行方式调用封装的类，通过classpath指定所有依赖的jar包和类路径。运行封装类，从系统标准输出中取得运行结果。
Public static String methodA (String param){ …… String rtStr = “”; String lStr=”<RTStr>”; String rStr=”<RTStr>”; //put all the dependency jar here String classPath=”/usr/WebSphere/conflict_v2.jar; /usr/WebSphere/workaroundConflict.jar;……”; String className=”com.ibm.test.WorkAround”; String cmdLine=”java -classpath ” +classPath +” ” +className + ” “+ param; Try{ Processprocess = Runtime.getRuntime().exec(cmdLine,null); process.waitFor(); BufferedReader br= new BufferedReader( new InputStreamReader(process.getInputStream())); while ((s = br.readLine())!=null) { if (null == out) ut=s; else out+=s;}//get result from outif (null != out){ int lIndex = out.lastIndexOf(lStr); int rIndex = out.lastIndexOf(rStr); rsStr = out.substring(lIndex+lStr.length, rIndex);} } catch (Exception e){ e.printStackTrace();}…….return rsStr;}
代码4：在应用程序中通过命令行方式运行WorkAround
*
命令行运行方式通过启动另外一个JVM的方式运行冲突代码，在一个不同的JVM中加载冲突的类，从而解决了jar包冲突问题。
但是命令行运行方式毕竟不是一个很好的方式，它存在以下的弊端：
* 命令行运行方式只适用于对冲突jar包的使用只是运行一段代码，或者只要求返回简单的字符串结果的情况。对于复杂的交互，命令行方式无法做到。但是如果在别无他法的情况下，可以适当地划分封装对冲突代码调用的jar包的包含范围，尽量将命令行运行的代码接口简单化。
* 命令行运行方式因为启动了另外一个JVM来运行，降低了WebSphere的性能。
因此，命令行方式只适用于一些极为特殊的情况下解决jar包冲突问题。
结论
本文对基于WebSphere的大型项目开发中遇到的jar包冲突问题，结合 WebSphere中类加载器的概念，给出了三种解决办法以及相应的操作步骤和实现代码，并分析了各种方式所适用的具体情况。
项目开发过程中的 jar包冲突，主要存在以下三种情况：
* 多个应用程序间的jar包冲突
* 应用程序内多个Web模块间的jar包冲突
* 应用程序内同一个Web模块内部jar包冲突
通过对类加载器的分析我们知道，解决jar包冲突问题的根本在于合理配置类加载器。在深入理解WebSphere中类加载器的层次结构的基础上，我们给出了”共享库解决jar包冲突”以及”打包到Web模块中解决jar 包冲突”的办法，通过合理地配置WebSphere中类加载器及其委托模式，可以解决大多数的jar包冲突问题。但是由于这个层次结构中类加载器只配置到 Web模块，因此，对于Web模块内部的jar包冲突问题，类加载器的配置是无法解决的，为此我们给出了”命令行运行方式解决jar包冲突”的办法。
表 2中列出了在不同的WAS版本下，三种解决jar包冲突问题的办法所适用的jar包冲突情况。
表2：Jar包冲突解决办法适用的jar包冲突情况总结