To clarify our situation a bit, the activation bundle finds its own META-INF/mailcap.defaults but is unable to see META-INF/mailcap in the javamail bundle because of the separation of classloaders. Given this needed relationship, I believe we've run out of options except to put activation and javamail in the same bundle.
We also have the Felix commons-email bundle deployed but it only brings along org/apache/commons/mail/ classes. The pom for that artifact explicitly excludes javax.mail and javax.activation. ----- "Carsten Ziegeler" <cziege...@apache.org> wrote: > I think we faced this problem when we just bundle mail and activation > a > long time ago. I don't remember the details, but the bundle at Apache > Felix Commons: > http://svn.apache.org/repos/asf/felix/trunk/commons/mail > > should already contain everything you need and work :) > > HTH > Carsten > > Ian Boston wrote: > > The problem is: > > > > we have > > javax.mail in bundle A as mail.jar > > javax.activation in bundle B as activation.jar > > > > These jars have no OSGi activation but just export javax.mail.* and > > javax.activation.* respectively. > > > > and a 3rd bundle that tries to send an email encoded as plain/text. > > > > This causes, the exception below since META-INF/mailcap.default > inside > > activation.jar is not found. > > > > We (I should say Carl Hall as he can take all the investigation > credit) > > think that this would normally have been loaded when a static class > > inside mail was loaded, perhaps with a context classloader (not > sure > > about that). > > > > I think that one work around will be to force the static into > existence > > inside the appropriate bundle probably activation, but I wondered > if > > there is a standard way to load resources cross bundle in Felix ? > > > > Ian > > > > > > Caused by: javax.activation.UnsupportedDataTypeException: no object > DCH > > for MIME type text/plain > > at > > > javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:885) > > at > javax.activation.DataHandler.writeTo(DataHandler.java:316) > > at > javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1350) > > at > javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1683) > > at > > com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:585) > > ... 13 more > > > > On 26 Oct 2009, at 22:09, Karl Pauls wrote: > > > >> There is no such thing as buddy classloading in OSGi and we don't > have > >> something like this in the felix framework either. Maybe you can > >> explain a bit about what the problem is exactly and we can see > whether > >> there is a different solution... > >> > >> regards, > >> > >> Karl > >> > >> On Mon, Oct 26, 2009 at 10:50 PM, Ian Boston <i...@tfd.co.uk> > wrote: > >>> Hi, > >>> We have a situation using javax.mail and javax.activation as > bundles in > >>> Sling where the resources (META-INF/mailcap* ) inside the > activation > >>> jar are > >>> not visible. > >>> > >>> I understand from others that if the OSGi container was Equinox, > >>> Eclipse-BuddyPolicy et al would fix the problem (ie buddy > >>> classloading). Is > >>> there a way to achieve the same thing in Sling with Felix or are > we > >>> going to > >>> have to start intercepting the context classloader which comes in > >>> somewhere? > >>> > >>> Ian > >>> > >> > >> > >> > >> -- > >> Karl Pauls > >> karlpa...@gmail.com > > > > > > > -- > Carsten Ziegeler > cziege...@apache.org
