我使用 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 文件夹中，您可能会遇到错误和奇怪的行为。
有没有关于这个问题的最佳实践或官方文件？您对此有何看法？
最佳答案
将依赖的 jar 打包到 war 文件中可能会产生更大的 war 文件，但它提供了很多好处。大型 war 文件成为一个独立的、完整的部署单元。您可以获取该 war 文件并将其部署到开发人员桌面、客户验收环境和生产环境，并确信您在 war 文件中的代码引用了所有依赖项的预期版本。
根据我的经验，唯一将 jar 文件而不是 war 文件放入 Tomcat 的 lib 文件夹的情况是当您的代码通过接口(interface)引用某个库时，并且直到部署时您才知道底层实现。例如，我有一个与 JMS 集成的项目，我知道我必须支持消息基础设施的多个部署。一些环境需要使用 ActiveMQ。其他环境需要使用 Websphere MQ。在这种情况下，我将 JMS 接口(interface) jar 打包到 war 文件中，然后在部署时，我将 ActiveMQ 或 Websphere MQ 实现 jar 放入 tomcat/lib 中。
当然，这意味着 war 文件不再是一个完整的部署单元。相反，部署是一个两步过程。这是一个权衡。我认为这比管理多个 war 文件构建变体更容易，每个变体都捆绑一个不同的 JMS 提供程序 jar。
关于java - Tomcat 中的第三方库最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6397334/