You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Donald Whytock <dw...@gmail.com> on 2011/07/04 23:08:20 UTC
multipart/alternative mail not recognized
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
Re: multipart/alternative mail not recognized
Posted by bbk <br...@hotmail.com>.
Hi,
I have the same problem. What is the issue please?
Thank you
--
View this message in context: http://camel.465427.n5.nabble.com/multipart-alternative-mail-not-recognized-tp4551261p5750946.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: multipart/alternative mail not recognized
Posted by Donald Whytock <dw...@gmail.com>.
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
problematic.
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.
Don
On Tue, Jul 5, 2011 at 8:59 PM, Willem Jiang <wi...@gmail.com> 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<dw...@gmail.com>
>> 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<dw...@gmail.com>
>>> 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: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
Re: multipart/alternative mail not recognized
Posted by Willem Jiang <wi...@gmail.com>.
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<dw...@gmail.com> 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<dw...@gmail.com> 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: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: multipart/alternative mail not recognized
Posted by Donald Whytock <dw...@gmail.com>.
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 <dw...@gmail.com> 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 <dw...@gmail.com> 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
>>
>
Re: multipart/alternative mail not recognized
Posted by Donald Whytock <dw...@gmail.com>.
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 <dw...@gmail.com> 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
>