java.lang.ClassCastException：com.sun.mail.handlers.multipart_mixed无法转换为javax.activation.DataContentHandler [英] java.lang.ClassCastException: com.sun.mail.handlers.multipart_mixed cannot be cast to javax.activation.DataContentHandler

问题描述

该行 part.writeTo（out）;
引发 java.lang.ClassCastException ：

com.sun.mail.handlers.multipart_mixed无法转换为javax.activation.DataContentHandler

 私有静态无效getBodyAsRFC822（
 MimePart part，boolean ignoreHeaders，ByteArrayOutputStreamout）{
 try {
 out 。重启（）; 
 
 if（ignoreHeaders）{
 OutputStream os = MimeUtility.encode（out，part.getEncoding（））; 
 part.getDataHandler（）。writeTo（os）; 
 os.close（）; 
}否则{
 part.writeTo（out）; 
 out.close（）; 
} 
} 
捕获（异常e）{
 _log.error（e）; 
} 
} 
  

这是我的build.gradle

  compileOnly组：'com.liferay'，名称：'com.liferay.portal.instance.lifecycle'，版本：'2.0.0'
 compileOnly组： com.liferay.portal，名称： com.liferay.portal.kernel，版本： 2.46.0 
 compileOnly组： org.osgi，名称： org  .osgi.core，版本： 6.0.0 
 compileOnly组： org.osgi，名称： org.osgi.service.component.annotations，版本： 1.3.0 
 
 compileInclude组：'org.slf4j'，名称：'slf4j-api'，版本：'1.7.25'
 compileInclude组：'org.apache.mina'，名称：'mina-core '，版本：'2.0.16'
 compileInclude组：'javax.mail'，名称：'mail'，版本：'1.4'
 compileInclude组： javax.servlet，名称： servlet -api，版本： 2.5 
  

但是 multipart_mixed实现了DataContentHandler ，因此它应该是可转换的。为什么不呢？

解决方案

每当显然无法将子类转换为其合法超类时，您就有重复的类，由不同的类加载器加载。找到要在哪里加载激活（超类）类，消除除一个类（通常需要消除自己的项目带来的一个类）之外的所有类，并使用框架中提供的一个。

异常消息为有问题的类命名，但省略了参与游戏的类加载器，这就是为什么该消息在初次尝试时不会产生太大的作用感。一旦您了解了多个类加载器，即 javax.activation.DataContentHandler 的多个实例，就变得更加有意义。

编辑：在build.gradle中使用 compileInclude 语句，可以有效地将所有依赖项绑定到自己的jar文件中。但是，框架具有这些类的自己的版本，尽管它们都具有相同的名称，但是它们现在将是不同的版本（不仅是数字版本），并通过不同的类加载器加载。如果您显然依赖于OSGi运行时中永远找不到的内容，则仅应使用 compileInclude 。而是使用 compileOnly 或 compile 作为默认值，并将其他依赖项与模块一起部署到运行时。 / p>

检查此文章详细介绍了您所做的事情。

The line part.writeTo(out); throws java.lang.ClassCastException:

com.sun.mail.handlers.multipart_mixed cannot be cast to javax.activation.DataContentHandler

private static void getBodyAsRFC822(
        MimePart part, boolean ignoreHeaders, ByteArrayOutputStreamout) {
    try {
        out.reset();

        if (ignoreHeaders) {
            OutputStream os = MimeUtility.encode(out, part.getEncoding());
            part.getDataHandler().writeTo(os);
            os.close();
        } else {
            part.writeTo(out);
            out.close();
        }
    }
    catch (Exception e) {
        _log.error(e);
    }
}

This is my build.gradle

compileOnly group: 'com.liferay', name: 'com.liferay.portal.instance.lifecycle', version: '2.0.0'
compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.46.0"
compileOnly group: "org.osgi", name: "org.osgi.core", version: "6.0.0"
compileOnly group: "org.osgi", name: "org.osgi.service.component.annotations", version: "1.3.0"

compileInclude group: 'org.slf4j', name: 'slf4j-api', version: '1.7.25'
compileInclude group: 'org.apache.mina', name: 'mina-core', version: '2.0.16'
compileInclude group: 'javax.mail', name: 'mail', version: '1.4'
compileInclude group: "javax.servlet", name: "servlet-api", version: "2.5"

But multipart_mixed implements DataContentHandler, so it should be castable. Why isn't it?

解决方案

Whenever a subclass apparently can't be typecasted to its legitimate superclass, you have duplicate classes, loaded by different classloaders. Find where you load the activation (superclass) classes, eliminate all but one (typically you'll need to eliminate the one class that your own project brings) and use the provided one from the framework.

The Exception message names the classes in question but omits the classloaders participating in the game, which is why the message, on first attempt to understand it, doesn't make much sense. As soon as you know about multiple classloaders, thus multiple instances of javax.activation.DataContentHandler, it makes more sense.

Edit: With the compileInclude statements in your build.gradle, you're effectively bundling all your dependencies into your own jar file. But the framework has its own version of these classes, and while they all have the same name, they'll now be different versions (not only numeric), loaded through different classloaders. You should only use compileInclude if you clearly are dependent on something that you'll never find in the OSGi runtime. Instead, use compileOnly or compile as default, and deploy the additional dependencies to the runtime, together with your module.

Check this article for a detailed description of what you've done.

这篇关于java.lang.ClassCastException：com.sun.mail.handlers.multipart_mixed无法转换为javax.activation.DataContentHandler的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！