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<dwhyt...@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<dwhyt...@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
