文档介绍：Jar包冲突问题是在大型Java软件开发中经常遇到的问题,系统开发人员经常会为解决类似的问题耗费大量的时间进行调试和测试,本文根据各种际情况,结合WebSphere中类加载器,讨论了几种解决jar包冲突问题的办法,并给出了具体实现的步骤及源代码。读者定位为具有 Java和WebSphere开发经验的开发人员。读者可以学习到在WebSphere中类加载器的定义以及解决jar包冲突问题的几种办法,并可以直接使用文章中提供的Java代码,从而节省他们的开发和调试时间,提高效率。
大型的基于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,最下层是具体的应用程序,上下层之间形成父子关系。
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 会缓存这个类直至其生命周期结束,并把它和相应的类加载器关联在一起,这意味着不同的类加载器可以加载相同名字的类。
如果一个加载的类依赖于另一个或一些类,那么这些被依赖的类必须存在于这个类的类加载器查找路径上,或者父类加载器查找路径上。
如果一个类加载器以及它所有的父类加载器都无法找到所需的类,系统就会抛出Clas