camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: multipart/alternative mail not recognized
Date Wed, 06 Jul 2011 02:33:45 GMT
I haven't tried ServiceMix, no.  I don't believe this is a class
loading issue as much as a resource issue.  DataHandler looks for a
text file called mailcap, which cross-references email content types
and classes that handle them.  DataHandler looks in a few standard
places for it.

In the case of JavaMail, mailcap is inside the jar, in the META-INF
directory.  With a CLI application jars' resources are on the
classpath.  With an OSGi application they're a little more

I think the correct solution would be a change in JavaMail that more
explicitly connects DataHandler to the mailcap.  I'm discussing this
with people on the JavaMail forum, but I don't know what sort of
turnaround there is for changes there.  So I'll probably write a patch
for MailBinding.


On Tue, Jul 5, 2011 at 8:59 PM, Willem Jiang <> wrote:
> As you know there are big differences between the normal standalone JVM
> class loading and OSGi class loading. We did lots of work in ServiceMix
> bundles module to hunter down this kind of issues.
> I'm not sure what kind of error that you meet.Did you have a chance to run
> the test case within ServiceMix ?
> On 7/6/11 4:46 AM, Donald Whytock wrote:
>> Further research suggests it's a bug in JavaMail and/or DataHandler
>> that's related to OSGi.
>> I can code an app that uses JavaMail to check an email, and structure
>> it so it'll work as a bundle.  Running it standalone I see the message
>> content as MimeMultipart, which is correct.  Running it in Felix as a
>> bundle I see the message content as SharedByteArrayInputStream, which
>> is incorrect.
>> So this is a problem with either my Felix configuration or
>> Oracle/Sun/Kenai's OSGi bundling.  But it's independent of camel-mail.
>> So obviously I need to look at those two areas, but on the offchance
>> it's something particularly
>> subtle/complicated/bureaucratically-constrained, should I code a
>> workaround for MailBinding?
>> Don
>> On Tue, Jul 5, 2011 at 12:05 PM, Donald Whytock<>
>>  wrote:
>>> And the answer is, it's a bug.  MailBinding in camel-mail is looking
>>> for content of type Multipart, whereas what's coming through is
>>> javax.mail.util.SharedByteArrayInputStream.
>>> But that was reasonable, since the JavaMail javadoc says, "The object
>>> returned for a 'multipart' content is always a Multipart subclass. For
>>> content-types that are unknown to the DataHandler system, an input
>>> stream is returned as the content."
>>> So that means it looks like the bug is in the JavaMail DataHandler.
>>> Researching further...
>>> Don
>>> On Mon, Jul 4, 2011 at 5:08 PM, Donald Whytock<>
>>>  wrote:
>>>> Hi all...
>>>> I remember seeing posts regarding attachments before...not sure if
>>>> this is more of the same...
>>>> When I send email from Gmail I can send either rich-formatting or
>>>> plain text.  If I send plain text, my message gets through fine, with
>>>> a content-type of "text/plain".  But if I send it rich-formatting,
>>>> Gmail breaks it into two parts: a plain text body and a formatted
>>>> body, with UUID-style delimiters in between.  The content-type is
>>>> "multipart/alternative".
>>>> My consumer on a camel-mail endpoint sees the plaintext message with
>>>> no problem.  What I receive in the message body from the
>>>> multipart/alternative is both bodies plus the delimiters.
>>>> Is this a bug in how camel-mail is supposed to be functioning?  Or an
>>>> unimplemented feature?  I.e. something camel-mail is doing wrong or
>>>> something it isn't doing at all?
>>>> Don
> --
> Willem
> ----------------------------------
> FuseSource
> Web:
> Blog: (English)
> (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang

View raw message