java.lang.ClassCastException: com.sun.mail.handlers.multipart_mixed cannot be cast to javax.activation.DataContentHandler

Question

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?

it seems to be a classloading issue. Check the libs you have in your portlet or hook or any other component — Angelo Immediata, Mar 28 '19 at 17:19
Let's talk into chat. It's not correct for all other developers if we talk into italian — Angelo Immediata, Mar 28 '19 at 17:26
OK in the meantime give a look here https://stackoverflow.com/questions/21645071/using-gradle-to-find-dependency-tree — Angelo Immediata, Mar 28 '19 at 17:31
Hi Angelo, i'm new about StackOverflow. How can i open a chat with you ? — Simone Sorgon, Mar 29 '19 at 07:45

Olaf Kock · Accepted Answer · 2019-03-29T16:15:30.943

4

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.

edited Mar 29 '19 at 16:15

answered Mar 29 '19 at 10:54

Olaf Kock

46,930
8
59
90

Where i can find the activation (superclass)? – Simone Sorgon Mar 29 '19 at 11:09
I don't know, but you should be able to find it twice – Olaf Kock Mar 29 '19 at 11:51
Basically, what can I do? – Simone Sorgon Mar 29 '19 at 13:57
if you can, look my build.gradle.. i can to change "compileInclude group: 'javax.mail', name: 'mail', version: '1.4'" with "compileInclude group: 'javax.mail', name: 'javax.mail-api', version: '1.5.6'" and the exception disappears but the application does not do that before .. – Simone Sorgon Mar 29 '19 at 14:17
`compileInclude` will package the dependencies *in your module*, and most likely `javax.mail` (and with it `javax.activation`) is already provided by the OSGi container (Liferay in this case). Thus `compileOnly` should be ok: At compiletime you'll need the dependency, and at runtime you're dependent on the version of `javax.mail` that Liferay or another component provides through the OSGi container. As a rule of thumb, it should be rare that you're bundling dependencies within your own module. `compileInclude` will include `javax.mail` and `activation` in your module. – Olaf Kock Mar 29 '19 at 15:00
if i change compileInclude with compileOnly, the exception there is – Simone Sorgon Mar 29 '19 at 15:59
At least you have the root cause for this problem. Now find the others ;) – Olaf Kock Mar 29 '19 at 17:12

java.lang.ClassCastException: com.sun.mail.handlers.multipart_mixed cannot be cast to javax.activation.DataContentHandler

1 Answers1

Linked