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 Tue, 05 Jul 2011 20:46:56 GMT
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?


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

View raw message