javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed; boundary

Question

Currently I\'m inline of writing a code that will be listening to a directory. when the directory is updated with .apk file, I\'ll send a mail with this .apk file to a gmail

Answer 1

If it's a android project, it's highly possible the proguard stripped out unused classes by mistake, please add the following lines in the proguard file to fix the problem without modifying the code directly:

-keep class com.sun.mail.handlers.**
-dontwarn com.sun.mail.handlers.handler_base

Answer 2

Tell me more about the environment in which your code is running. What JDK are you using? Are you running in an application server?

The JavaBeans Activation Framework (JAF) looks for configuration files that tell how to map MIME types to the Java classes (DataContentHandlers) that handle them. It uses the ClassLoader to find the configuration files. If there are problems with the ClassLoader, the configuration files might not be found.

You might want to try the workaround described here, but of course it would be better to determine the root cause of the problem for you.

Finally, you might want to simplify your program by fixing some of these common JavaMail mistakes.

Answer 3

Som's answer (MailcapCommandMap) worked for me with Spring war Portlets in Liferay 7.1 ga1. However, I had to remove Tomcat's mail.jar from tomcat/lib/ext and replace it with javax.mail-1.6.2.jar, then make sure the dependency is scoped as provided in the project's pom.xml:

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>javax.mail</artifactId>
    <version>1.6.2</version>
    <scope>provided</scope>
</dependency>

Answer 4

Under OSGI, the following workaround allows the javax.activation bundle to load the "META-INF/mailcap" resource from the javax.mail bundle :

Thread.currentThread().setContextClassLoader(javax.mail.Message.class.getClassLoader());

Note : character sets conversions may have limitations with this workaround...

Answer 5

The answer from Som worked for me. However I had to modify the mappings as I was using JavaMail DSN, and needed those mailcap entries also (included below, including Som's answer):

// Original answer from Som:
MailcapCommandMap mc = (MailcapCommandMap) CommandMap.getDefaultCommandMap();
mc.addMailcap("text/html;; x-java-content-handler=com.sun.mail.handlers.text_html");
mc.addMailcap("text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml");
mc.addMailcap("text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain");
mc.addMailcap("multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed");
mc.addMailcap("message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822");

// Additional elements to make DSN work 
mc.addMailcap("multipart/report;;  x-java-content-handler=com.sun.mail.dsn.multipart_report");
mc.addMailcap("message/delivery-status;; x-java-content-handler=com.sun.mail.dsn.message_deliverystatus");
mc.addMailcap("message/disposition-notification;; x-java-content-handler=com.sun.mail.dsn.message_dispositionnotification");
mc.addMailcap("text/rfc822-headers;;   x-java-content-handler=com.sun.mail.dsn.text_rfc822headers");

As it turns out, it was adding the DSN JAR into my fat JAR (using shadowJar/Gradle) that caused the problem: the META-INF/mailcap from the DSN jar was overwriting the core one.