战争包与共享库内的依赖关系

Question

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

然而，也可能会下降的依赖关系到共享库中，使用相同的依赖关系为每个部署的工件的。

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

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

无论如何，一些点，每个：

里面包括WAR依赖关系：（？）

• “时点” 的方法
• 易于维护（需要更少的配置&脚本等）
• 易于部署到应用服务器
• 每个模块都可以在图书馆
定义特定版本210
• 减少类加载错误的风险？

使用共享库：

• 减少内存消耗（琐碎？）
• WAR部署可以访问相同的实例/变量等，因为它们共享类路径？这听起来真的很糟糕？ （它真的工作方式，或者是他们在不同的上下文中运行，只是使用相同的物理文件？）
• 了做分布和部署更加困难，因为依赖关系必须被单独维护/部署
• 包是在较小大小（平凡）
• 依赖最多可以升级，没有战争的应用程序的实际重新部署（有什么好处，真的..）

当然，我们可以使用两种方法的最好的方面，只是提供通用库作为共享库，并在WAR中包含版本特色。但是，这使维护工作倍增，感觉像是一个不行。

目前我使用Glassfish的3.1.1，但这个问题确实是应用服务器不可知。

Answer 1

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

如果你要战发送到已部署了服务器上的这场战争是非常恼人的第三方用户。穷人用户必须在他的共享库中安装所有必需的依赖关系（以及依赖关系的依赖关系）。

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

Answer 2

鉴于您上面的pro/con列表，它在我看来就像您已经回答了您的问题。正如你所说，内存/磁盘很容易来。另一方面，时间并不容易。将依赖关系放在WEB-INF/lib中被证明是很容易的，并且可以让应用程序避免与其他人或系统类加载器进行奇怪的交互。如果它没有被破坏...

Answer 3

好处就像你说的 - 每个应用程序都是独立的，即不需要立即在所有已部署的应用程序中升级库。加上只有类路径冲突，你应该期望的是，当相同的库在容器和应用程序 - 我不记得它很好，类加载可以在不同的容器中有所不同。

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

因此，建议是：保持标准方法，只检查您为不必要的依赖关系构建的WARs/JARs。