我正在使用 Tomcat 来托管我的Java Web和Web服务应用程序很长一段时间。主要用于 Spring 和 Grails 应用程序。
最近在一个项目中出现了关于如何处理Tomcat生产环境中的依赖项/库的讨论：
在我的项目中，我正在部署大WAR文件，其中包含WEB-INF / lib文件夹中应用程序的所有必需依赖项。我在tomcat / lib文件夹中放置的唯一内容是由tomcat管理的JDBC连接的JAR文件。
客户与WebSphere有着悠久的历史，并认为容器应该包含大部分所需的依赖项。因此，他们希望将已使用的框架或WebService API（如Metro）的JAR文件放在tomcat / lib文件夹中，并且具有瘦的WAR文件。
我认为该解决方案存在的问题是，如果您的应用程序需要另一个已包含在tomcat / lib文件夹中的依赖项版本，则可能会出现错误和奇怪的行为。
是否有一些最佳实践或官方文件可以讨论这个问题？你对此有何看法？
答案 0 :(得分：7)
将依赖的jar包装到war文件中可能会产生更大的war文件，但它提供了很多好处。大战争文件成为一个单独的，独立的，完整的部署单元。您可以获取该war文件并将其部署到开发人员桌面，客户接受环境和生产环境，并确信war文件中您自己的代码引用了所有依赖项的预期版本。
根据我的经验，将jar放入Tomcat的lib文件夹而不是war文件的唯一时间是当您的代码通过接口引用某个库时，在部署时间之前您将不知道底层实现。例如，我有一个与JMS集成的项目，我知道我必须支持消息传递基础架构的多个部署。某些环境需要使用ActiveMQ。使用Websphere MQ所需的其他环境。在这种情况下，我将JMS接口jar打包到war文件中，然后在部署时，我将ActiveMQ或Websphere MQ实现jar放入tomcat / lib。
当然，这意味着war文件不再是一个完整的部署单元。相反，部署过程分为两步。这是一种权衡。我认为这比管理多个war文件构建变体更容易，每个变量捆绑一个不同的JMS提供者jar。
答案 1 :(得分：4)
是否有一些关于此问题的最佳做法或官方文件？
我怀疑你会发现官方文件（来自Tomcat开发者/社区）支持这一理论，尽管它非常有效。我必须在之前的工作中准备一个，以便可以跨多个J2EE容器部署应用程序的EAR文件。
但有一点值得赞成。您可以打开标题为"WebSphere Application Server V6.1: Classloader Problem Determination"的IBM红皮书（考虑到WAS 7可用，已经过时了），它演示了如何在WebSphere中创建共享库。在WebSphere上，可以为需要不同版本的应用程序创建多个此类库。在Tomcat上，鉴于all shared libraries is dumped into $CATALINA_HOME\lib，你可能不知道类加载器是什么的管理员的怜悯。
红皮书也有这方面的建议（用实用程序JAR替换实用程序文件，你有答案）：
您不应放置实用程序文件的位置
决定最佳放置位置 实用文件，重要的是 认识到这些文件不应该 包含在WebSphere中 Application Server的环境。
例如：app_server_root / lib， app_server_root / lib，/ ext *， app_server_root / java（包括任何 子目录）或JVM类路径。
将实用程序文件添加到这些文件 目录可能会导致问题 WebSphere运行时环境和 会导致意想不到的结果 包括覆盖WebSphere 可能对此有害的类 服务器的整体功能。
答案 2 :(得分：0)
我会选择可选套餐：http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/index.html
步骤：
将您的代码，库打包在jar / war中。
在上面的MANIFEST.MF中声明扩展名单jars
在目标应用程序中引用它们