第三方库在Tomcat中的最佳实践 [英] Third party libraries best practice in Tomcat

问题描述

我正在使用 Tomcat 来托管我的Java Web和Web服务应用程序很长一段时间。主要用于 Spring 和 Grails 应用程序。

I am using Tomcat for hosting my Java Web and Web Service applications for a long time now. Mostly for Spring and Grails applications at the moment.

最近在一个项目中讨论了如何处理Tomcat生产环境中的依赖项/库：

Lately in one project a discussion came up, about how deal with dependencies/libraries in Tomcat production environments:

在我的项目中，我正在部署大WAR文件，其中包含WEB-INF / lib文件夹中应用程序的所有必需依赖项。我在tomcat / lib文件夹中放置的唯一内容是由tomcat管理的JDBC连接的JAR文件。

In my projects I am deploying big WAR files holding all the required dependencies for the application in WEB-INF/lib folder. The only things I put in the tomcat/lib folder are the JAR files for JDBC connections managed by tomcat.

客户与WebSphere有着悠久的历史，并认为容器应该包含大部分所需的依赖项。因此，他们希望将已使用的框架或WebService API（如Metro）的JAR文件放在tomcat / lib文件夹中，并且瘦的WAR文件。

The customer has a long history with WebSphere and thinks the container should hold most of the the required dependencies. So they want to put JAR files for used frameworks or WebService API's (like Metro) in the tomcat/lib folder and have skinny WAR files.

在我看来，该解决方案的问题在于，如果您的应用程序需要已包含在tomcat / lib文件夹中的其他版本的依赖项，则可能会出现错误和奇怪的行为。

The problem with that solution in my opinion is that if you have an application that requires another version of a dependency that is already included in the tomcat/lib folder you can get errors and strange behavior.

是否有一些最佳实践或官方文件谈论这个问题？您对此有何看法？

Is there some best practice or official document that talks about this issue? What is your opinion about this?

推荐答案

是否有一些最佳做法或官方文件谈到这个问题？

我怀疑你会找到官方文件（来自Tomcat开发者/社区）来支持这个理论虽然很有效。我不得不在之前的工作中准备一个，以便可以跨多个J2EE容器部署应用程序的EAR文件。

I doubt you will find official documents (from the Tomcat developers/community) to support this theory, although it is very valid. I had to prepare one in my previous job, so that the EAR file of the application could be deployed across multiple J2EE containers.

但有一点是有利的。您可以打开名为WebSphere Application Server V6.1：类加载器问题确定的IBM红皮书（非常过时，因为WAS 7可用），它演示了如何在WebSphere中创建共享库。在WebSphere上，可以为需要不同版本的应用程序创建多个此类库。在Tomcat上，你是一个可能不知道类加载器是什么的管理员的怜悯，因为所有共享库都被转储到$ CATALINA_HOME \lib 。

There is one thing in favour though. You can bring up the IBM Redbook titled "WebSphere Application Server V6.1: Classloader Problem Determination" (quite dated, given that WAS 7 is available) which demonstrates how to created shared libraries in WebSphere. On WebSphere, one can create multiple such libraries for applications that require differing versions. On Tomcat, you are the mercy of an administrator who may not know what a class loader is, given that all shared libraries is dumped into $CATALINA_HOME\lib.

红皮书也有这方面的建议（替换实用程序文件）使用实用程序JAR并且您有答案）：

The Redbook also has this bit of advice (replace utility file with utility JAR and you have your answer):

您不应放置实用程序文件的位置

在决定最佳放置
实用程序文件的位置时，重要的是
认识到这些文件不应该包含在
中的
中$ b Application Server的环境。

In deciding where best to place your utility files, it is important to recognize that these files should not be included in the WebSphere Application Server’s environment.

例如：app_server_root / lib，
app_server_root / lib，/ ext *，
app_server_root / java（包括任何
子目录）或JVM类路径。

For example: app_server_root/lib, app_server_root/lib,/ext* , app_server_root/java (including any subdirectories), or the JVM classpath.

将实用程序文件添加到那些
目录可能会导致
出现问题WebSphere运行时环境和
可能会导致意外结果，
包括覆盖WebSphere
类，这些类可能对服务器的
整体功能有害。

Adding utility files to those directories can cause problems with the WebSphere runtime environment and can cause unexpected results, including the overwriting of WebSphere classes that can be detrimental to the overall functionality of the server.

这篇关于第三方库在Tomcat中的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！