EmailSrv / multipart : java.lang.ClassCastException: com.sun.mail.imap.IMAPInputStream cannot be cast to javax.mail.Multipart

1,443 views
Skip to first unread message

Nicolas Micoud

unread,
Feb 27, 2018, 4:40:06 AM2/27/18
to iDempiere
Hi,

Since i migrating from 2.1 to 5.1, i got those error messages when trying to integrate emails :

10:16:00.780-----------> mail.loadResource: expected resource not found: {0} (/META-INF/javamail.default.providers) [9772]
10:16:00.780-----------> mail.loadResource: expected resource not found: {0} (/META-INF/javamail.default.address.map) [9772]
10:16:00.855===========> EMailIntegration.importMailAndAttachmentsMib: java.lang.ClassCastException: com.sun.mail.imap.IMAPInputStream cannot be cast to javax.mail.Multipart [9772]

EMailIntegration.importMailAndAttachmentMib is my own util class (called by a process) to do some stuff on DB and call EmailSrv.processMessage.
Error is thrown from EmailSrv.analysisEmailStructure at line 468 when trying to put msg.Content in a Multipart.
Something must have been broken between 2.1 and 5.1, but i don't know what.

Any idea ?

Thanks,

Nicolas

Anozi Mada

unread,
Feb 27, 2018, 5:30:29 AM2/27/18
to iDempiere
When searching for this issue I found that a lot of people also encounter the exact same issue.
Maybe you can try a solution from here https://javaee.github.io/javamail/FAQ#castmultipart

Q: When reading a multipart message, why is the getContent method returning an IMAPInputStream (or SharedByteArrayInputStream) instead of a MimeMultipart object?
A: This usually happens because the JavaBeans Activation Framework (JAF) can't find the mailcap configuration file included in the javax.mail.jar file. JAF uses the thread's context class loader to look for the configuration file. If the context class loader is not set properly, this can fail. Most application servers should set the context class loader properly, but at least some versions of Tomcat do not. One workaround is to put the javax.mail.jar file in Tomcat's lib directory instead of including it in the war file. Another workaround is to add code such as the following to the beginning of your application:
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());

 Not sure though why your 2.1 environment is fine. Maybe it's a jetty thing?

Regards,
Anozi Mada

Nicolas Micoud

unread,
Feb 27, 2018, 11:11:53 AM2/27/18
to iDempiere
Hi,
Seems related to setup (see https://issues.apache.org/jira/browse/KARAF-4154).
That's far beyond my skills :-/

I use a workaround to deal with the issue (use an external program).

But i can help to test if someone can propose a patch.

Thanks,


Nicolas
Reply all
Reply to author
Forward
0 new messages