I am getting the following exception when I try to send email using JavaMail. This error began happening when we upgraded to Java 1.6. It does not happen with earlier versions of Java.
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed; boundary="----=_Part_0_2882193.1230049431911"
I have browsed through the forums and read the many postings with a similar error. I have tried the variety of suggestions, but nothing seems to work. My understanding is the JAF is included in Java 1.6, so we should not need the activation.jar in our classpath anymore. Even so I have tried with and without the activation.jar in the classpath. I do not think it is a class loader issue because we do not build any of this into our application. It is all referenced in jar files on the classpath.
The interesting thing is that I can launch the application with a normal JVM launch and it works just fine. The error only occurs when I launch the application from a C++ application using JNI. In both cases I am using the exact same classpath. The error occurs whether I include activation.jar in the classpath or not.
I have tried to programmatically add the MIME types using the MailCommandMap class, but this had no effect.
The most recent test I ran was to put the activation.jar and mail.jar files in my C:\Java\jre6\lib\endorsed directory. This actually cleared up the error. This is not a viable solution for us, but it leads me to believe the .mailcap file is not being loaded correctly for some reason. I just cannot figure out what the issue could be as it seems to be associated with JNI.
Thank you for any help,
You don't mention what environment your application is running in, but whatever it is the
problem is that something is not setting the thread's context class loader to point to the
application's class loader. If you're running in an application server or some other framework,
that's probably what's broken. If you're running a standalone application, then it's your
application that needs to set it. You might be able to work around the problem by adding
something like this to the beginning of your application:
Thank you for your suggestion. I added that line of code to the initialization of our application and that seems to have fixed/worked-around the problem.
Our application is stand-alone, it does not run within an application server framework. We are simply launching it from a C++ program using JNI. I am curious why in this situation we must manually set the Thread's context class loader. I have not had to manually set a class loader before to get external jar files loaded properly. Is this an issue with JNI?
Thank you for your help. I really appreciate it.
Because JAF is now part of the JDK, the JAF classes are loaded by the system class loader
instead of the application class loader. If the thread's context class loader is not set, JAF
uses its class loader to load the mailcap files. Since JavaMail's mailcap file is in mail.jar,
and mail.jar is still loaded by the application class loader, the system class loader can't
find JavaMail's mailcap file.
Normally, when starting the application using the "java" command, the thread's context
class loader will be set to the application's class loader. This may not be happening
automatically when starting the application with JNI.
thanx a lot, guys !
I was struggling to fix an issue with 'javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed' in the mail appender for log4j library, which failed with the error when request to reload log4j configuration was sent through JMX.
And your suggestion to add 'Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());' did solve my issue.