第三方库在Tomcat中的最佳实践
我现在使用Tomcat来托管我的Java Web和Web Service应用程序很长一段时间。 主要用于Spring和Grails应用程序。
最近，在一个项目中，讨论了如何处理Tomcat生产环境中的依赖项/库：
在我的项目中，我正在部署大型WAR文件 ，其中包含WEB-INF / lib文件夹中应用程序的所有必需依赖项。 我在tomcat / lib文件夹中放置的唯一内容是由tomcat管理的JDBC连接的JAR文件。
客户与WebSphere有着悠久的历史，并认为容器应该包含大部分所需的依赖项。 因此，他们希望将已使用的框架或WebService API（如Metro）的JAR文件放在tomcat / lib文件夹中，并具有瘦的WAR文件 。
我认为该解决方案的问题在于，如果您的应用程序需要已包含在tomcat / lib文件夹中的其他版本的依赖项，则可能会出现错误和奇怪的行为。
是否有一些最佳实践或官方文件谈论这个问题？ 你对此有何看法？
是否有一些最佳实践或官方文件谈论这个问题？
我怀疑你会发现官方文件（来自Tomcat开发者/社区）来支持这个理论，尽管它非常有效。 我不得不在之前的工作中准备一个，以便可以跨多个J2EE容器部署应用程序的EAR文件。
但有一点值得赞成。 您可以打开标题为“WebSphere Application Server V6.1：类加载器问题确定”的IBM红皮书（鉴于WAS 7可用，已经过时了），它演示了如何在WebSphere中创建共享库。 在WebSphere上，可以为需要不同版本的应用程序创建多个此类库。 在Tomcat上，由于所有共享库都被转储到$ CATALINA_HOME \ lib中 ，因此您可能不知道类加载器是什么的管理员的怜悯。
红皮书也有这方面的建议（用实用程序JAR替换实用程序文件，你有答案）：
你不应该放置实用程序文件的地方
在决定放置实用程序文件的最佳位置时，必须认识到这些文件不应包含在WebSphere Application Server的环境中。
例如：app_server_root / lib，app_server_root / lib，/ ext *，app_server_root / java（包括所有子目录）或JVM类路径。
将实用程序文件添加到这些目录可能会导致WebSphere运行时环境出现问题，并可能导致意外结果，包括覆盖可能对服务器的整体function有害的WebSphere类。
将依赖包装的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。
我会选择可选包： http ： //docs.oracle.com/javase/6/docs/technotes/guides/extensions/index.html
脚步：
-
打包你的代码，库在jar / war中。
-
在上面的MANIFEST.MF中声明了扩展名列表jar
-
在目标应用程序中引用它们