战争包与共享库中的依赖关系[关闭]答案

【问题标题】：Dependencies inside war-package vs. shared libraries [closed]战争包与共享库中的依赖关系[关闭]
【发布时间】：2011-12-14 16:30:04
【问题描述】：

通常，依赖项捆绑在 Java .war-packages 中。

但是，也可以将依赖项放入共享库中，以便为每个已部署的工件使用相同的依赖项。

问题：每种方法的优缺点是什么？您会在哪些情况下使用它们？

最大的要求是直观性/可维护性。我不太在意内存消耗、磁盘空间使用、带宽等，因为它们很便宜。

总之，各有几分：

在 WAR 中包含依赖项：

使用共享库：

当然，我们可以利用这两种方法的最佳方面，只提供公共库作为共享库，并在 WAR 中包含版本特性。但是，这会使维护工作加倍，感觉就像是禁忌。

目前我使用的是 Glassfish 3.1.1，但这个问题与应用服务器无关。

【问题讨论】：

有趣，看来我必须更详细地阅读常见问题解答。我想我提出了两个严格的问题——考虑到直观性/可维护性，询问什么是好的以及在什么情况下选择这两种方法。我一般没有问哪个更好——这取决于每个人自己根据给出的事实来决定。我什至给出了一个很好的扩展起点，实际上得到了建设性的答案。

【解决方案1】：

这取决于您的操作。如果您将应用程序部署在您的服务器上并且此类服务器的数量非常有限（例如集成、QA、生产）并且您有很多依赖项可以将依赖项放入共享库。

如果您要将战争发送给必须在其服务器上部署此战争的第三方用户，这非常烦人。可怜的用户必须在他的共享库中安装所有必需的依赖项（以及依赖项的依赖项）。

如果您必须在不属于您的服务器或必须运行多个企业应用程序的服务器上安装您的应用程序，您就不能使用此方法。您必须将所有依赖项打包到您的 war 文件中。否则冲突是不可避免的。

【讨论】：

【解决方案2】：

优势如您所说-每个应用程序都是独立的，即您不需要一次升级所有已部署应用程序中的库。另外，只有当同一个库在容器和应用程序中时才会发生类路径冲突——我记不太清了，并且类加载在不同的容器中可能会有所不同。

如果您指的是“WAR 部署”各种应用程序，请不要期望共享任何内容 - 这些都是设计隔离的。共享依赖项可以在磁盘上单独升级，但何时以及如何发生取决于容器的类加载器。

因此建议是：保持标准方法，仅检查您构建的 WAR/JAR 是否存在不必要的依赖关系。

【讨论】：

【解决方案3】：

鉴于您上面的赞成/反对列表，在我看来您已经回答了您的问题。正如您所说，内存/磁盘很容易获得。另一方面，时间来之不易。将依赖项放入 WEB-INF/lib 是经过验证的、简单的，并且可以防止您的应用程序与其他人或系统类加载器发生奇怪的交互。如果它没有坏...

【讨论】：