如何在 WebSphere 中解决 jar 包冲突

ar包冲突问题实际上就是应用程序希望用某一个确定版本的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包冲突的问题。

项目是一个基于maven的web项目，依赖于公司的核心包。问题是在eclipse下部署成功，但在idea下部署失败。报错如下：

调查发现把项目部署在eclipse中时，lib目录下的jar包是正常的；部署到idea中以后，tomcat目录下webapps，进入到项目目录中，发现lib目录下有两个核心包，一个老版本，一个新版本。

于是到idea中查看了target目录下，是有两个核心包的，核心包被加载了两次，当然冲突了。下图是target目录：

所以就手动删除了老版本的核心包，重启以后项目就跑起来了。

冲突的jar包会显示成这样，一个是灰色的表示正常，另一个是黑色的应该的没什么用，但是却被错误的引入了进来，导致了项目无法启动，所以要将黑色的包删掉。

后记：

刚开始看日志报错一直以为是配置错误，还在jar包里看配置文件看是否哪里重复了，最后还是耐心看日志，发现在报错前已经加载了一遍配置文件，而且日志上写的很清楚，第一次加载的是老版本核心包的配置文件，然后加载新版本的配置文件就报错了。

所以排查问题时不能只看报错的那一行，要联系上下文，前后都得看一看。

---