Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-447

ClassCastException when storing multipart message without Msg ID

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Invalid
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.3.0
    • Labels:
      None

      Description

      This problem occurs with James HEAD, but not with James 2.2.0

      When sending a multipart message which has no Message-ID header field to an internal user, the following exception is raised:

      javax.mail.MessagingException: Exception caught while storing Message Container: javax.mail.MessagingException: MIME part of type "multipart/mixed; boundary="bmQykoPt9wvlXeBFetOZnNCi/trubV+f25KeVm5YJYo="" contains object of type com.sun.mail.util.SharedByteArrayInputStream instead of MimeMultipart
      at org.apache.james.mailrepository.AvalonMailRepository.store(AvalonMailRepository.java:329)
      at org.apache.james.transport.mailets.ToMultiRepository.storeMail(ToMultiRepository.java:226)
      at org.apache.james.transport.mailets.ToMultiRepository.service(ToMultiRepository.java:151)
      at org.apache.james.transport.mailets.LocalDelivery.service(LocalDelivery.java:64)
      at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:414)
      at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:397)
      at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:306)
      at java.lang.Thread.run(Thread.java:534)

      the exception is thrown within JavaMail, the last related James call is in line 67 of MimeMessageUtil:

      public static void writeTo(MimeMessage message, OutputStream headerOs, OutputStream bodyOs, String[] ignoreList) throws IOException, MessagingException {
      if (message instanceof MimeMessageCopyOnWriteProxy) {
      MimeMessageCopyOnWriteProxy wr = (MimeMessageCopyOnWriteProxy) message;
      MimeMessage m = wr.getWrappedMessage();
      if (m instanceof MimeMessageWrapper)

      { MimeMessageWrapper wrapper = (MimeMessageWrapper)m; wrapper.writeTo(headerOs, bodyOs, ignoreList); return; }

      } else if (message instanceof MimeMessageWrapper)

      { MimeMessageWrapper wrapper = (MimeMessageWrapper)message; wrapper.writeTo(headerOs, bodyOs, ignoreList); return; }

      if(message.getMessageID() == null)

      { message.saveChanges(); //// <====== exception thrown from here }

      the exception is going away if at least one of the following is done:
      + a message id header field is added when sending the message
      + the receiver is not a James internal account
      + the message mime type is changed from "multipart" to something else
      + James 2.2.0 is being used.

      I did the first one for the stress test tool, but wonder if a Message-ID is mandatory.
      I debugged this problem but did not find neither a fix nor the critical change from 2.2.0

      1. MimeMessageUtilTest.java
        4 kB
        Stefano Bagnara
      2. test.zip
        2 kB
        Bernd Fondermann

        Activity

        Hide
        brainlounge Bernd Fondermann added a comment -

        further note: reproduction possible with JavaMail 1.3.2, 1.3.3, 1.4ea. there seems to be no regression there.

        Show
        brainlounge Bernd Fondermann added a comment - further note: reproduction possible with JavaMail 1.3.2, 1.3.3, 1.4ea. there seems to be no regression there.
        Hide
        brainlounge Bernd Fondermann added a comment -

        a unit test reproducing the bug

        Show
        brainlounge Bernd Fondermann added a comment - a unit test reproducing the bug
        Hide
        bago Stefano Bagnara added a comment -

        I downloaded your test and ran against latest trunk and it passes.
        I don't see a ClassCastException in your stacktraces.

        Please test it against javamail 1.3.2 (we have sources for it) and report the full javamail stacktrace.

        Show
        bago Stefano Bagnara added a comment - I downloaded your test and ran against latest trunk and it passes. I don't see a ClassCastException in your stacktraces. Please test it against javamail 1.3.2 (we have sources for it) and report the full javamail stacktrace.
        Hide
        bago Stefano Bagnara added a comment -

        Furthermore: check that you don't have bogus "mailcap" files somewhere in your classpath.

        Show
        bago Stefano Bagnara added a comment - Furthermore: check that you don't have bogus "mailcap" files somewhere in your classpath.
        Hide
        bago Stefano Bagnara added a comment -

        A simpler test with no dependencies on MimeMessageWrapper/Source and no file operations.
        This test passes too. Please let me know if it passes in your environment too.

        Show
        bago Stefano Bagnara added a comment - A simpler test with no dependencies on MimeMessageWrapper/Source and no file operations. This test passes too. Please let me know if it passes in your environment too.
        Hide
        brainlounge Bernd Fondermann added a comment -

        both still fail with the same stacktrace:

        javax.mail.MessagingException: MIME part of type "multipart/alternative; boundary="XyoYyxCQIfmZ5Sxofid6XQVZt5Z09XtTnqBF4Z45XSA="" contains object of type com.sun.mail.util.SharedByteArrayInputStream instead of MimeMultipart
        at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1113)
        at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:1927)
        at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:1908)
        at org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:67)
        at org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:45)
        at org.apache.james.core.MimeMessageUtilTest.testWriteMimeMessageMultipartWithMessageID(MimeMessageUtilTest.java:40)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)

        Show
        brainlounge Bernd Fondermann added a comment - both still fail with the same stacktrace: javax.mail.MessagingException: MIME part of type "multipart/alternative; boundary="XyoYyxCQIfmZ5Sxofid6XQVZt5Z09XtTnqBF4Z45XSA="" contains object of type com.sun.mail.util.SharedByteArrayInputStream instead of MimeMultipart at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1113) at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:1927) at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:1908) at org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:67) at org.apache.james.core.MimeMessageUtil.writeTo(MimeMessageUtil.java:45) at org.apache.james.core.MimeMessageUtilTest.testWriteMimeMessageMultipartWithMessageID(MimeMessageUtilTest.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
        Hide
        brainlounge Bernd Fondermann added a comment -

        mmhh... when I run ./build.sh run-unit-tests, the test passes. I always ran the test through my IDE, for debugging.
        seem not reproducible this way. sigh.

        Show
        brainlounge Bernd Fondermann added a comment - mmhh... when I run ./build.sh run-unit-tests, the test passes. I always ran the test through my IDE, for debugging. seem not reproducible this way. sigh.
        Hide
        bago Stefano Bagnara added a comment -

        run a recursive search (also in jars) for mailcap or mailcap.default
        You probably have a bad mailcap in your classpath.

        Show
        bago Stefano Bagnara added a comment - run a recursive search (also in jars) for mailcap or mailcap.default You probably have a bad mailcap in your classpath.
        Hide
        brainlounge Bernd Fondermann added a comment -

        ok, I'll do that. thanks for the support.

        Show
        brainlounge Bernd Fondermann added a comment - ok, I'll do that. thanks for the support.
        Hide
        brainlounge Bernd Fondermann added a comment -

        to avoid running into the wrong direction: i'd have to look at James' classpath (not the application sending the message), right?

        Show
        brainlounge Bernd Fondermann added a comment - to avoid running into the wrong direction: i'd have to look at James' classpath (not the application sending the message), right?
        Hide
        bago Stefano Bagnara added a comment -

        You should look in the classpath of the application that throws the exception.
        http://java.sun.com/products/javabeans/glasgow/javadocs/javax/activation/MailcapCommandMap.html

        maybe you could test this: CommandMap.getDefaultCommandMap().getAllCommands("multipart/report");

        Then you cycle the CommandInfo to see what is the full class name of the class that is creating your problems. If you know its name it will be easier to find it in your classpath.

        Show
        bago Stefano Bagnara added a comment - You should look in the classpath of the application that throws the exception. http://java.sun.com/products/javabeans/glasgow/javadocs/javax/activation/MailcapCommandMap.html maybe you could test this: CommandMap.getDefaultCommandMap().getAllCommands("multipart/report"); Then you cycle the CommandInfo to see what is the full class name of the class that is creating your problems. If you know its name it will be easier to find it in your classpath.
        Hide
        brainlounge Bernd Fondermann added a comment -

        can't cycle. the expression returns an empty array CommandInfo[0]. what can i learn from this?
        i'll keep digging for mailcaps and try to set up an alternative environment.

        Show
        brainlounge Bernd Fondermann added a comment - can't cycle. the expression returns an empty array CommandInfo [0] . what can i learn from this? i'll keep digging for mailcaps and try to set up an alternative environment.
        Hide
        brainlounge Bernd Fondermann added a comment -

        can't cycle. the expression returns an empty array CommandInfo[0]. what can i learn from this?
        i'll keep digging for mailcaps and try to set up an alternative environment.

        Show
        brainlounge Bernd Fondermann added a comment - can't cycle. the expression returns an empty array CommandInfo [0] . what can i learn from this? i'll keep digging for mailcaps and try to set up an alternative environment.
        Hide
        bago Stefano Bagnara added a comment -

        I don't know. Run a recursive search for the mailcap files and post here their position/content.
        What IDE do you use? If eclipse, have you installed any third party plugin?

        Can you also try to remove (or comment out) the first line of the "mailcap" file in src/META-INF ?

        Show
        bago Stefano Bagnara added a comment - I don't know. Run a recursive search for the mailcap files and post here their position/content. What IDE do you use? If eclipse, have you installed any third party plugin? Can you also try to remove (or comment out) the first line of the "mailcap" file in src/META-INF ?
        Hide
        bago Stefano Bagnara added a comment -

        Bernd: any update on this? Have you find any solution to the problem?
        I would like to close this because I think it should not be a problem in the james codebase, but I would like to have a confirmation from you that you found the problem, before.

        Show
        bago Stefano Bagnara added a comment - Bernd: any update on this? Have you find any solution to the problem? I would like to close this because I think it should not be a problem in the james codebase, but I would like to have a confirmation from you that you found the problem, before.
        Hide
        brainlounge Bernd Fondermann added a comment -

        meanwhile I put the alpha into a separate directory and everything went fine. (so I suggest you close this issue.)
        this tells me that the problem does not come from any user-account-specific mailcap file because all three james' (2.2.0, 2.3.0a1, HEAD) are run from the same command line under the same account and PATH.

        on trunk the problem still occurs. i poked around in some mailcap files, but no immediate resolution. so the only possible way to tackle the problem I see right now is to collect all mailcaps systematically (like you suggested a long time ago) after performing a fresh checkout.

        Show
        brainlounge Bernd Fondermann added a comment - meanwhile I put the alpha into a separate directory and everything went fine. (so I suggest you close this issue.) this tells me that the problem does not come from any user-account-specific mailcap file because all three james' (2.2.0, 2.3.0a1, HEAD) are run from the same command line under the same account and PATH. on trunk the problem still occurs. i poked around in some mailcap files, but no immediate resolution. so the only possible way to tackle the problem I see right now is to collect all mailcaps systematically (like you suggested a long time ago) after performing a fresh checkout.
        Hide
        bago Stefano Bagnara added a comment -

        Please comment here if you have updates so that I reopen this one instead of creating a new issue.

        Show
        bago Stefano Bagnara added a comment - Please comment here if you have updates so that I reopen this one instead of creating a new issue.
        Hide
        sypecom Sylvain Pedneault added a comment -

        I've been fighting with this issue all day (and just fixed it). I was getting "...contains object of type com.sun.mail.util.SharedByteArrayInputStream instead of MimeMultipart" error messages on e-mails I couldn't find anything wrong with. The errors started occuring after upgrading from JavaMail 1.3 to 1.4. To upgrade, I had simply swapped the "mail.jar" file with the newest version (not using the invididual narrower .jar files in the JavaMail distribution, but instead using the fat mail.jar one).

        But when I opened the JavaMail 1.4 distribution, I also noticed a "dsn.jar" file. Instinctively, and misreading the file name, I trashed our "dns.jar" library and dropped in that "dsn.jar" file from JavaMail 1.4! (notice dNS and dSn is not the same Well, turns out that not only was it not the replacement library I though it was, but dsn.jar also contains a "mailcap" file. As soon as I removed dsn.jar, the error disappeared.

        So, to all of you who get the SharedByteArrayInputStream-thing error, do you have JavaMail 1.4's "dsn.jar" file in your classpath? Could it be the source of the problem? Sure seems to have fixed it here....

        Show
        sypecom Sylvain Pedneault added a comment - I've been fighting with this issue all day (and just fixed it). I was getting "...contains object of type com.sun.mail.util.SharedByteArrayInputStream instead of MimeMultipart" error messages on e-mails I couldn't find anything wrong with. The errors started occuring after upgrading from JavaMail 1.3 to 1.4. To upgrade, I had simply swapped the "mail.jar" file with the newest version (not using the invididual narrower .jar files in the JavaMail distribution, but instead using the fat mail.jar one). But when I opened the JavaMail 1.4 distribution, I also noticed a "dsn.jar" file. Instinctively, and misreading the file name, I trashed our "dns.jar" library and dropped in that "dsn.jar" file from JavaMail 1.4! (notice dNS and dSn is not the same Well, turns out that not only was it not the replacement library I though it was, but dsn.jar also contains a "mailcap" file. As soon as I removed dsn.jar, the error disappeared. So, to all of you who get the SharedByteArrayInputStream-thing error, do you have JavaMail 1.4's "dsn.jar" file in your classpath? Could it be the source of the problem? Sure seems to have fixed it here....
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            brainlounge Bernd Fondermann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development