7 Replies Latest reply on Feb 13, 2012 6:46 AM by ctomc

    mailcap: no object DCH for MIME type




      I've been running with an issue using java mail on JBoss AS 7.1.0.CR1b.



      I can't give you sadly all the details, but here is the code used to call java mail:

      Transport transport = null;

      try {

                                    javax.mail.Session session = MailSession.instance();

                                    transport = session.getTransport();


                                    transport.sendMessage(mimeMessage, mimeMessage.getAllRecipients());

      } finally {

                                    try { transport.close(); } catch (Exception e) { }




      And with a specific mime type I get the following exception:


      javax.mail.MessagingException: IOException while sending message;

        nested exception is:

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


          at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1141) [mail-1.4.4.jar:1.4.4]

          at mypackage.MyClass.sendEmail(MyClass.java:361) [MyProject.jar:]

          ... 68 more

      Caused by: javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/related;


          at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:905) [activation-1.1.1.jar:1.1.1]

          at javax.activation.DataHandler.writeTo(DataHandler.java:330) [activation-1.1.1.jar:1.1.1]

          at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1476) [mail-1.4.4.jar:1.4.4]

          at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1772) [mail-1.4.4.jar:1.4.4]

          at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1099) [mail-1.4.4.jar:1.4.4]

          ... 69 more


      After some investigations, I figured out that actually the module javax.activation resolves the mime type using the META-INF/mailcap file. But it actually looks for this file using the current thread's class loader (ie the application's class loader). Since, javax mail's mailcap is in mail.jar in the javax.mail.api module, it can't be found with the default configuration.



      There is actually a workaround, is to add in the jboss-deployement-structure.xml the following dependency:

      <module name="javax.mail.api"><imports><include path="META-INF"/><include path="META-INF/**"/></imports></module>


      Then, the application's class loader will resolve the module's META-INF/mailcap.


      I wonder then, shouldn't the default module dependency to javax.mail.api include META-INF for any J2EE project ?


      Thank you very much.

        • 1. Re: mailcap: no object DCH for MIME type



          The problem you are mentioning was fixed in 7.1.x builds of AS7 and was only present in 7.0.x builds.


          Your investigation is right, activation.jar loads mailcap file from mail.jar, in case of AS7 that you get is that javax.mail.api is dependant on javax.activation.api and javax.activation.api has dependency on javax.mail.api where it imports META-INF from it and nothing else.

          you can see this here: https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/modules/javax/activation/api/main/module.xml


          So from what I would guess your problem is something with your dependencies, maybe you have activation.jar or mail.jar packed inside your application or you don't have all necessary dependencies for your deployment.


          Have you tried injecting or looking up mail session that you configure in application server from jndi?

          Does it work with that one? As it is tested and proven to work at least if you have everything right with your installation.

          And also check what lib you have bundled in you application and what is configured as dependencies in jboss-deployement-structure.xml


          By default you wouldn't need to declare javax.mail.api or javax.activation.api dependencies as they should be included by default and when they are imported as they should be.


          By default when you add depenancy by jboss-deployement-structure.xml or by MANIFEST.MF you only import classes and nothing else, you have to explicitly import other stuff (annotations,services,additional resource files)



          hope anything of this helps,


          1 of 1 people found this helpful
          • 2. Re: mailcap: no object DCH for MIME type



            We're actually both right. My trouble went from the fact that while my application does not contains the activation or mail jars, it does contains a custom mailcap.


            If we look at the code of javax.activation.MailcapCommandMap.loadAllResources(List, String) [claeed by MailcapCommandMap.<init>() line:177], it actually load the files either from the Application's class loader, and (if there isn't a context class loader, or if nothing had been loaded) it use the local module's class loader. Since that the presence of a custom mailcap disable the loading of the default mailcap..

            • 3. Re: mailcap: no object DCH for MIME type

              Hi !


              I just run with a similar issue, since I updated to JBoss AS 7.1-Final nightly built from 6th January.


              javax.mail.NoSuchProviderException: No provider for smtp

                      at javax.mail.Session.getProvider(Session.java:464) [mail-1.4.4.jar:1.4.4]

                      at javax.mail.Session.getTransport(Session.java:659) [mail-1.4.4.jar:1.4.4]

                      at javax.mail.Session.getTransport(Session.java:640) [mail-1.4.4.jar:1.4.4]

                      at javax.mail.Session.getTransport(Session.java:626) [mail-1.4.4.jar:1.4.4]



              Here is my configuration:


              My web application contains Seam 2.2.2, which has a META-INF/javamail.providers.


              In javax.mail.Session.loadProviders(Class cl):

              loadAllResources("META-INF/javamail.providers", cl, loader);

              => load Seam 2.2.2's mock provider.


              loadResource("/META-INF/javamail.default.providers", cl, loader);

              => should load Java Mail's default providers, but given class is org.jboss.as.mail.extension.MailSessionService$PasswordAuthentication, which has no access to java mail's META-INF


              if (providers.size() == 0)

                 pr("DEBUG: failed to load any providers, using defaults");


              => unfortunately, Seam's mock loader has been loaded, and no default will be loaded.



              Workaround :


              In the module org.jboss.as.mail, replace

              <module name="javax.mail.api"/>


              <module name="javax.mail.api"><imports><include path="META-INF"/></imports></module>

              • 4. Re: mailcap: no object DCH for MIME type



                nice catch, can you create jira issue and I will make a fix for it.



                • 5. Re: mailcap: no object DCH for MIME type




                  I’m afraid, there are still a lot of issues with the way the mailcap files are loaded



                  In my case, my javax.mail.api contains a couple of jars: mail-1.4.4.jar and dsn-1.4.4.jar.



                  I use a SMTP log4j logger (SMTPAppender), which I wrapped in a Log4jAppenderHandler which is itself wrapped into a home made SMTPHandler used in my standalone.xml configuration.

                  So, in the org.apache.log4j module I added dependencies to the javax.mail.api module and my module containing my SMTPHandler.



                  When it comes to logging, I’ve got once again the “no object DCH for MIME type” exception. Here is what actually happens when the mailcap files are loaded:



                  In the MailcapCommandMap constructor, it calls loadAllResources(dbv, "META-INF/mailcap");


                  Here, ClassLoader cld = SecuritySupport.getContextClassLoader(); is the ModuleClassLoader for Module "org.jboss.as.logging:main"


                  So, with the default module configuration is does not find any mailcap file.

                  Then, the flag anyLoaded is set the false. Therefore it calls:

                  MailcapFile mf = loadResource("/" + name);

                       if (mf != null)


                  which calls:

                  clis = SecuritySupport.getResourceAsStream(this.getClass(), name);



                  Fortunately, javax.activation.api has a dependency to javax.mail.api including META-INF. But this code actually load only ONE mailcap file, in my unlucky case it's the one from dsn-1.4.4.jar and not from mail-1.4.4.jar.



                  A first workaround would be for me to add a dependency to javax.mail.api in org.jboss.as.logging importing META-INF. Then, in loadAllResources, it would load all the mailcap files instead of only one, thanks to urls = SecuritySupport.getResources(cld, name);



                  But, this is actually not going to work. Because, my application as also a custom mailcap file which won’t be loaded since the object MailcapCommandMap has been instanced. A work around would be for me to call at startup javax.activation.CommandMap.setDefaultCommandMap(new MailcapCommandMap()); from my application to use its classloader (having imported META-INF of javax.mail.api in jboss-deployment-structure.xml).



                  Anyway, it seems the way the mailcap files are handled is a nightmare with the JBoss module’s classloader isolation. Because, if I happen to deploy many application with different mailcap config, I won’t be able to use them at the same time, since the mailcap configuration is static.

                  • 6. Re: mailcap: no object DCH for MIME type



                    Should I open a JIRA for this case then ?


                    Please let me know,


                    Thank you.

                    • 7. Re: mailcap: no object DCH for MIME type



                      please do, but as you have pointed out yourself it is basicly issue of classloading isolation.

                      IMHO, what you are trying to do you should be doing inside of your application but I also see a point in having this globably.