代码之家 › 专栏 › 技术社区 › karlgrz

JAVA EE JAR文件共享

java-ee jsf tomcat java

1

karlgrz · 技术社区 · 16 年前

在我们的商店,我们正在维护大约20个JavaEE Web应用程序。这些应用程序中的大多数在其体系结构中相当粗糙,其中一些应用程序是相当处理器密集的计算应用程序。

为了部署这些应用程序,我们一直在使用Hudson设置来监视我们的CVS存储库。当我们有一个签入时,项目被设置为编译并部署到我们的Tomcat6.0服务器上。( Solaris 10、SPARC双核1.6 GHz处理器、2 GB RAM……不是想象中最强大的机器…… )而且,如果项目存在任何单元测试,则执行这些测试,并且只有在单元测试通过时才部署项目。这很管用。

现在,随着时间的推移,我注意到我创建的许多项目反复使用相同的.jar文件(Hibernate、POI(Excel输出)、SQL Server JDBC驱动程序、JSF、IceFaces、Business Logic.jar文件等)。我们的做法是在我们的网络驱动器上保留一个文件夹,其中存储着我们一直使用的所有默认.jar文件,当一个新项目启动时,我们将这组.jar文件复制到新项目中,然后从那里开始…我觉得是这样的。 肮脏的 每次发生这种情况,我都会在晚上不睡觉。我的同事告诉我,在Tomcat服务器上建立一个.jar存储库“非常困难”,这是我一秒钟都不买的…我把它归因于纯粹的懒惰,可能也不想学习最佳实践。我可能错了,不过,我只是在陈述我对这件事的感受。这似乎膨胀了部署到服务器上的.war文件的大小。

据我所知,Tomcat本身有一组.jar文件,部署到它上面的所有应用程序都可以访问这些文件,所以我认为我们可以在所有项目中合并所有这些重复的.jar文件,并将它们移到Tomcat服务器上。例如,如果我们需要将icefaces.jar文件更新到新版本,那么只需要更新服务器上的一个.jar文件。

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

我的直觉告诉我,我想把那些复制的.jar文件移到服务器上……这样行吗?

4 回复 | 直到 16 年前

1

2

duffymo 16 年前

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

关于在每个项目中复制jar与将它们放入服务器/lib之间的争论,我认为这取决于一点:您希望同时升级部署在Tomcat上的每个应用程序的可能性有多大?你能想象一个时间,在那台服务器上运行n个应用程序,而(n+1)第n个应用程序可能需要或需要一个特定jar的更新版本吗?

如果你不介意让所有的应用程序保持同步,那么一定要让它们使用一个公共的库库库。

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

2

1

stevedbrown 16 年前

它在大多数情况下都有效,但是您可能会遇到一些令人恼火的情况,即您移入Tomcat的JAR正试图在某个Web应用程序JAR中创建类的实例,从而导致抛出ClassNotFoundException。我以前做过这个,但因为这些问题而停了下来。

3

1

diega 16 年前

我真的不认为把库放在common/lib中是个好主意。将war文件用作servlet容器中的应用程序背后的想法是真正了解webapps之间的隔离。您可能会遇到一些错误,例如部署第三方战争(在WEB-INF/LIB中有它自己的库),并且它的行为异常,因为它从公共库加载了一个IT库的其他版本(请记住,加载类的常规行为是首先查看公共类加载器,如果找不到该类,请查看其中一个你的webapp)。甚至不要提到将一些应用程序移动到其他servlet容器或应用程序服务器会有多痛苦。如前所述,您可以使用Maven来处理JAR依赖关系,如果您喜欢库的同构使用,那么可以在所有应用程序中定义一个POM父级(Maven行话)。

4

1

Thorbjørn Ravn Andersen 16 年前

根据我的经验,通过将库移动到Web容器本身,您应该非常小心地在Web应用程序之间共享库。

让他们生活在WEB-INF/LIB中,这样你的战争就可以自给自足了(总有一天你会高兴的)。

您可能会考虑使用Maven或AntIvy从公共存储库中提取库jar。这非常有用,在您的场景中不应该是一个问题。

编辑:一个显著的例外是Metro库——GlassFish的Web服务层——它需要在Web容器中而不是在Web应用程序中。