处理重复罐子的最佳做法是什么答案

【问题标题】：What is the best practice to handle duplicate jars处理重复罐子的最佳做法是什么
【发布时间】：2011-12-30 03:43:35
【问题描述】：

我正在将 JBPM5.2 包含到我现有的项目中。我注意到一些 jar 文件是重复的。以下是列表

我的 jbpm 激活-1.1.jar 1.1 1.1 antlr-2.7.7.jar 2.7.7 2.7.7 共同收藏 2.1 3.1 通用 io 1.1 1.4 dom4j-1.6.1.jar 1.6.1 1.6.1 Jdom-1.0.jar 1.0 1.0 Jta.jar 1.0 1.1 日志4j 1.2.15 1.2.14 邮件.jar 1.4 1.4

我并不热衷于升级这些 jar，因为这意味着我必须对我现有的很多功能进行彻底的回归测试。基本上我正在寻找一种安全简便的方法。

我相信这是很多人都会遇到的一个非常普遍的问题。有人可以与我分享他/她解决此问题的方法吗？

【问题讨论】：

标签： jar classloader conflict

【解决方案1】：

那么，您的应用对 jbpm 有什么样的依赖关系？ jbpm 和你的 jar 会在同一个类加载器下的同一个 JVM 中吗？如果是这样，你就有问题了。升级是唯一正确的解决方案。

通常，在 Web 应用程序（例如 Tomcat 或 Jetty）中，服务器所需的库位于服务器的类路径中。每个正在部署的 Web 应用程序都有自己的类加载器。您所依赖的库在此类加载器上可用，不会污染容器本身。

【讨论】：

【解决方案2】：

我能想到的选项很少

如果您的部署单元是 EAR（我不确定这是否适用于您的应用思想）。由于 WAR 可以有自己的类加载器，因此您可以将 jar 本地化到 webapp。浏览这篇帖子Java EE class loading standard
另一种可能性是将 JBPM 作为单独的应用程序单独部署。
升级 jars（我的偏好）：据我所知，commons-* 是唯一在 MINOR 版本中也推迟该功能的 jars。因此，您无需担心任何事情。您可能只需要一个冒烟测试或简单的功能测试。

【讨论】：