Java EE Jar文件共享

Question

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

为了部署这些应用程序，我们一直在使用Hudson来监控我们的CVS存储库。当我们进行检查时，这些项目将被设置为编译并部署到我们的Tomcat 6.0服务器（Solaris 10，sparc双核1.6 GHz处理器，2 GB RAM ......不是任何一端想像力...），如果项目存在任何单元测试，则执行这些测试，并且仅在单元测试通过时才部署项目。这很好。 （Hibernate，POI（Excel输出），SQL Server JDBC驱动程序，JSF，ICEFaces等）创建的许多项目都会重复使用相同的.jar文件。现在，随着时间的推移，业务逻辑.jar文件等）。我们的做法是在我们的网络驱动器上保存一个文件夹，其中储存了我们一直使用的所有默认.jar文件，当新项目启动时，我们将这组.jar文件复制到新项目中并从那里开始。 ..我觉得如此脏每次发生这种情况，它已经开始让我在晚上。我的同事告诉我，在tomcat服务器上建立一个.jar存储库是“非常困难的”，我不会再买一秒钟......我把它归结为纯粹的懒惰，没有学习最佳实践的欲望。我可能是错的，但是，我只是陈述我对这件事的感受。这似乎也扩大了我们部署到服务器的.war文件的大小。

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

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

我的直觉告诉我，我想将这些重复的.jar文件移动到服务器上......这样做会工作吗？

Answer 1

我认为Maven和Ivy出生的目的是帮助管理JAR依赖关系。也许你会发现那些帮助很大。至于有关在每个项目中复制JAR而不是将它们放入服务器/ lib的争论，我认为这取决于一点：您是否有可能要升级部署在Tomcat上的每个应用程序与此同时？你能设想一个时间，你可能有N个应用程序在该服务器上运行，而第（N + 1）个应用程序可能需要或需要更新版本的特定JAR？

如果你不介意让所有的应用程序保持同步，通过任何方式让他们使用一个共同的库基地。

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

Answer 2

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

Answer 3

我真的不认为把图书馆放在一起/ lib是一个好主意。使用war文件作为应用程序到servlet容器中的想法是让你的web应用程序有一个真正的隔离概念。您可能会面临像部署第三方WAR（在WEB-INF/lib中拥有自己的库）的错误，并且它会意外地表现出它的行为，因为它会从普通的库中加载其中一个库的其他版本（请记住，加载类的常规行为是首先看一下普通的类加载器，如果你没有发现这个类看起来像你的webapp）。甚至没有提到将某些应用程序移动到其他servlet容器或应用程序服务器是多么痛苦。 如前所述，您可以使用maven来处理jar依赖关系，如果您喜欢同类库的使用，请在所有应用程序中定义一个POM父项（maven术语）。

Answer 4

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

让他们生活在WEB-INF/lib中，这样你的战争是自成一体的（你会很高兴你有一天会这样做）。

您可能会考虑使用maven或Ant常春藤来从公共存储库中提取库罐。这是非常有用的，在你的情况下不应该是一个问题。

---

编辑：一个值得注意的例外是地铁库 - 从Glassfish的Web服务层 - 这需要在Web容器，而不是在Web应用程序。