war-package与共享库中的依赖关系

Question

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

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

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

最大的要求是直观性/可维护性。我不太关心内存消耗，磁盘空间使用，带宽等等，因为这些都很便宜。

无论如何，每个都有一些要点：

在WAR中包含依赖项：

• “事实上的”方法（？）
• 易于维护（需要较少的配置和脚本等）
• 易于部署到应用服务器
• 每个模块都可以在库上定义特定版本
• 降低类加载错误的风险？

使用共享库：

• 减少内存消耗（微不足道？）
• WAR部署可以访问相同的实例/变量等，因为它们共享类路径？它听起来真的很糟糕？ （它是否真的以这种方式工作，或者它们是在单独的上下文中运行，只使用相同的物理文件？）
• 由于必须单独维护/部署依赖关系，因此使分发和部署更加困难
• 包的尺寸较小（平凡）
• 依赖关系可以升级而无需实际重新部署WAR应用程序（有什么好处，真的......）

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

目前我正在使用Glassfish 3.1.1，但这个问题实际上与app服务器无关。

Answer 1

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

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

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

Answer 2

优点如您所说 - 每个应用程序都是自包含的，即您不需要同时在所有已部署的应用程序中升级库。加上你应该期待的类路径冲突是当同一个库在容器和应用程序中时 - 我不能很好地回想起它，并且类加载在各种容器中可能不同。

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

所以建议是：保持标准方法，只检查你为不必要的依赖构建的WAR / JAR。

Answer 3

鉴于您的上述赞成/反对意见清单，我认为您已经回答了您的问题。如你所说，内存/磁盘很容易获得。另一方面，时间并非如此容易。将依赖项放在WEB-INF / lib中是经过验证的，简单易用，并使您的应用程序不会与其他人或系统类加载器进行奇怪的交互。如果没有破产......