javamail jar的多个版本导致NoSuchProviderException

Question

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

jar文件将所有依赖项捆绑在jar中（使用maven shade插件），包括javamail jar文件。

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

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

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

编辑：

我通过javamail API进行了调试。我发现javax。邮政会话构造com类型的新对象。太阳邮政smtp。SMTPTransport使用反射并将两个参数传递给构造函数，但它尝试从另一个邮件使用SMTPTransport，而不是使用位于同一jar文件中的SMTPTransport。jar位于一个部署的应用程序中。

Answer 1

将Tomcat 7附带的JavaMail版本升级到JavaMail 1.5.3版本，其中包含错误6668的修复-跳过不可用的存储和传输类。您可以从JavaMail参考实现主页下载最新的快照和官方版本。

Answer 2

我不熟悉maven-shade-plugin。它是否将原始jar文件打包到新jar文件中？它是否提取原始jar文件的内容并将内容插入到新jar文件中？如果是后者，它可能只包括类文件，而不包括配置JavaMail提供程序的META-INF中的资源文件。

当然，最好的方法是安排仅将JavaMail jar文件的一个副本包含在服务器的类路径中。

Answer 3

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

1. 首先是WEB-INF/classes
2. 然后在WEB-INF/lib的JAR中
3. 如果没有找到该类，则仅在您的\u SERVER\u HOME/lib中
4. 然后在系统类加载器上，如下所述

其他战争中的类版本（在Class/WEB-INF/lib上）无法从另一个战争中看到。

您能否告知我们有助于追踪问题的更多信息：

>

如何将独立库添加到服务器类路径？它是复制到您的服务器HOME/lib上的，还是通过共享添加到服务器类路径的文件夹。加载器或普通。catalina的装载机属性。属性

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

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

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

>

如果您使用的是Java7，请尝试使用JHades对不同应用程序的类路径进行故障排除。您可以对重复类的WAR进行静态分析，或者查看给定类运行时使用的版本以及哪些其他版本可用。

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

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

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

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