java - 多个版本的 javamail jar 导致 NoSuchProviderException

Question

我有一个独立的库(jar 文件)，它被添加到应用程序服务器类路径以监控 JVM 中所有正在运行的应用程序并在出现问题时发送电子邮件。

jar 文件将所有依赖项捆绑在 jar 中(使用 maven-shade-plugin)，包括 javamail jar 文件。

当 appserver 中的其他 web 应用程序之一将 javamail 作为依赖项时，我的 jar 文件中的 javamail 会发生一些依赖项冲突，我得到一个异常

MessagingException :javax.mail.NoSuchProviderException: No provider for smtp 

知道我无法修改正在运行的应用程序，我该如何解决这个冲突。我只能控制我的 jar 文件。

编辑:

我通过 javamail API 进行了调试。我发现 javax.mail.Session 使用反射构造一个 com.sun.mail.smtp.SMTPTransport 类型的新对象并将两个参数传递给构造函数，而不是使用位于同一 jar 文件中的 SMTPTransport 它试图使用位于已部署应用程序之一中的其他 mail.jar 中的 SMTPTransport。

Answer 1

在 tomcat 7 中，默认情况下 web 应用程序将首先按以下顺序查找类:

1. 首先在 WEB-INF/classes 上
2. 然后在 WEB-INF/lib 中的 jar 里
3. 如果在 YOUR_SERVER_HOME/lib 中找不到该类
4. 然后在系统类加载器上，如所述here

来自其他 WAR 的类版本(在类/WEB-INF/lib 上)在另一个 WAR 中是不可见的。

能否让我们知道更多信息以帮助追踪问题:

• 独立库更详细地做了什么，它如何监控其他应用程序？

• 如何将独立库添加到服务器类路径？它是复制到 YOUR_SERVER_HOME/lib 上，还是通过 catalina.properties 的 shared.loader 或 common.loader 属性添加到服务器类路径的文件夹

• 每个 WAR 应用程序是否在 WEB-INF/lib 上提供它自己的邮件 jar，或者库是否作为 JNDI 资源在服务器级别发布，如提到的 here在安装 JavaMail 库

部分

• 服务器中是否有任何应用程序未在我上面提到的默认类加载模式下运行，并且正在使用 delegate = true(这意味着它将首先在服务器上查看，然后才在 WAR 上查看)？ here这是如何配置的，检查 context.xml 或 server.xml 中的 Resource 元素

一些可能的解决方案建议:

1. 按照安装说明将 JavaMail 作为 JNDI 资源安装在 tomcat 7 上 here在 安装 JavaMail 库 部分。让所有应用程序都像 tomcat 文档中那样使用 JNDI 资源，并使用 shade 插件排除从独立库中删除 java 邮件。这将始终有效，并且是最受推荐的解决方案。

2. 如果您使用的是 Java 7，请尝试使用 JHades对不同应用程序的类路径进行故障排除。您可以对重复类的 WAR 进行静态分析，或者查看给定类在运行时使用的版本是什么，还有哪些版本可用。

3. 由于无法控制其他应用程序或其内容的部署设置、JNDI 的使用等，因此在所有环境和任何应用程序中都可以确保有效的解决方案是重构该工具，以便它不需要在服务器上安装 mail.jar。该工具可以将电子邮件请求写入文件或数据库表，部署在服务器上的另一个 WAR 将轮询表文件并发送邮件。或者调用 bash/bat 脚本，它本身在单独的 java 进程上发送电子邮件。

Dynatrace 等性能分析工具基于 JVM 代理并使用类似的机制，不需要在服务器级别引入库，代理收集数据并将其发送到收集进程，该收集进程将其存储在某处以供进一步分析, 处理如通过邮件发送告警等。

希望这会有所帮助，一般来说，我看不到有任何方法可以将库部署到 EE 服务器，并确保它们永远不会对不同服务器类型和不同应用程序类加载设置上的任何应用程序造成问题。

最好的办法可能是调整该工具，使其依赖于部署在服务器上的最少库，将其分解为单独的模块，仅在服务器上运行收集模块，或者研究替代方案，例如 Dynatrace。