Java EE Jar 文件共享

Question

在我们的商店，我们维护着大约 20 个 Java EE Web 应用程序。这些应用程序中的大多数在其架构中都非常类似于 CRUD，其中一些是处理器密集型计算应用程序。

为了部署这些应用程序，我们一直使用 Hudson 设置来监控我们的 CVS 存储库。当我们签入时，项目将被编译并部署到我们的 Tomcat 6.0 服务器（Solaris 10、sparc 双核 1.6 GHz 处理器、2 GB RAM...不是最强大的机器）想象力......）并且，如果项目存在任何单元测试，则执行这些单元测试并且仅在单元测试通过时才部署项目。这很好用。

现在，随着时间的推移，我注意到自己创建的许多项目一遍又一遍地使用相同的 .jar 文件（Hibernate、POI（Excel 输出）、SQL Server JDBC 驱动程序、JSF、ICEFaces、业务逻辑 .jar 文件等）。我们的做法是在我们的网络驱动器上保留一个文件夹，其中存放了我们一直在使用的所有默认 .jar 文件，当一个新项目启动时，我们将这组 .jar 文件复制到新项目中并从那里开始。 ..每次发生这种情况时，我都感到很脏，它开始让我彻夜难眠。我的同事告诉我，在 tomcat 服务器上建立一个 .jar 存储库“非常困难”，我一秒钟都没有购买……我将其归因于纯粹的懒惰，并且可能，不想学习最佳实践。我可能是错的，但是，我只是在表达我对此事的感受。这似乎也增加了部署到服务器的 .war 文件的大小。

据我了解，Tomcat 本身有一组 .jar 文件可供部署到它的所有应用程序访问，因此我认为我们可以将所有这些重复的 .jar 文件合并到所有项目中并移动它们到tomcat服务器上。这将只涉及更新服务器上的一个 .jar 文件，例如，如果我们需要将 ICEFaces .jar 文件更新到新版本。

我的另一部分说，通过在服务器上只包含一个 .jar 文件的副本，我可能还需要在我的开发环境中保留服务器的 lib 目录的副本（即在 eclipse 中包含那些 .jar 文件依赖）。

我的直觉告诉我，我想将那些重复的 .jar 文件移动到服务器上……这行得通吗？

Answer 1

它在大多数情况下都有效，但您可能会遇到烦人的情况，即您移入 tomcat 的 jar 试图在您的一个 Web 应用程序 jar 中创建一个类的实例，从而导致 ClassNotFoundException 被抛出。我曾经这样做过，但因为这些问题而停止了。

Answer 2

我认为 Maven 和 Ivy 的诞生是为了帮助管理 JAR 依赖项。也许你会发现这些很有帮助。

关于在每个项目中复制 JAR 与将它们放在服务器/lib 中的争论，我认为这取决于一点：您想要升级部署在 Tomcat 上的每个应用程序的可能性有多大同时？您是否曾设想过某个时候，您可能会在该服务器上运行 N 个应用程序，而第 (N+1) 个应用程序可能需要或需要特定 JAR 的更新版本？

如果您不介意让所有应用保持同步，请务必让它们使用公共库库。

我个人认为磁盘空间很便宜。我的偏好是为每个应用程序复制 JAR 并将它们放入 WAR 文件中。我喜欢分区。当 OSGi 变得更加主流时，我希望看到更多。

Answer 3

我真的不认为将库放在 common/lib 中是个好主意。使用 war 文件作为应用程序到 servlet 容器中的想法是真正了解您的 webapps 之间的隔离。您可能会遇到错误，例如部署一些第三方 WAR（在 WEB-INF/lib 中具有自己的库），并且它的行为异常，因为它从公共库中加载了其中一个库的其他版本（请记住，加载类的常规行为是首先查看常见的类加载器，如果您没有找到该类，请查看适用于您的 webapp 的类）。更不用说将一些应用程序移动到其他 servlet 容器或应用程序服务器是多么痛苦。 如前所述，您可以使用 maven 处理 jar 依赖关系，如果您喜欢库的同质使用，请在所有应用程序中定义 POM 父级（maven 术语）。

Answer 4

根据我的经验，您应该非常小心地在 Web 应用程序之间共享库，方法是将它们移动到 Web 容器本身。

让他们生活在 WEB-INF/lib 中，这样你的战争就可以自给自足了（你会很高兴有一天你做到了）。

您可能会考虑使用 maven 或 Ant Ivy 从公共存储库中提取库 jar。这非常有用，在您的场景中应该不是问题。

---

编辑：一个值得注意的例外是 Metro 库 - Glassfish 的 Web 服务层 - 它需要位于 Web 容器中而不是 Web 应用程序中。