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 <willem.ji...@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<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 >
