Thanks. This is more what I had in mind.
I'll confer with Bill to ensure that META-INF/mailcap is the only file
impacted (and if it's not, I'll send you a list w/ justification).
Looking forward to testing your patch. I can sync with JavaMail.
Thanks again.
-Peter
Sahoo wrote:
> Looking at the all the emails, I decided to reply to the original
> posting to avoid confusion. Our class loader hierarchy looks something
> like this (-> indicates classloader delegation):
>
> /Application Class Loader (e.g., WebAppClassLoader) -> //Common Class
> Loader (lib, domain/lib, etc) -> //"API Class Loader" -> Extension
> Class Loader (java.ext.dirs) -> Bootstrap Class Loader (null)
> /
> (Some intermediate loaders have been excluded from the above
> delegation chain)
>
> "API Class Loader" is a gateway to OSGi world. It already takes care
> of META-INF/Services files. We can change this class loader to be
> friendly with JAF and search META-INF/mailcap files in all installed
> OSGi bundles. Once we do this, the only change JavaMail folks have to
> do is to export the implementation classes (I suggest them to use
> *Class Filtering* if they don't want to export all the classes from
> that package), as any exported class can be loaded by our "API Class
> Loader." As long as JavaMail is used by Java EE applications in
> GlassFish, this will work.
>
> With this solution, because of delegation hierarchy, a call to
> /
> "Application Class Loader."getResources("META-INF/mailcap") /
>
> would return mailcap files found in any of the following places:
> rt.jar,
> any jar in java.ext.dirs,
> any OSGi bundle (this includes javax.mail.jar),
> any jar in any of glassfish library directories,
> application archive itself (.war or ejb.jar etc.).
>
> I think this is the correct behavior.
>
> Peter,
>
> I can send you a patch privately to try out. You have to change
> JavaMail bundle to export those classes to get things working.
>
> Thanks,
> Sahoo
>
> Peter Williams wrote:
>> I'm investigating a JavaMail failure in V3 that is caused by the
>> current OSGi configuration and I'm trying to figure out how to fix it.
>>
>> The issue is this: Code in the JDK (JAF in this case) is calling
>> getResources() on the current context classloader (web app
>> classloader in my test case, but probably could another one) to
>> locate any available mailcap files. It's trying to find
>> META-INF/mailcap.default in javax.mail.jar. This fails, the code
>> breaks. Outside of OSGi, this all works fine.
>>
>> So what needed to happen here to make this work? Should
>> javax.mail.jar be exporting META-INF? How? Does the JDK have to
>> import this? (how?!)
>>
>> Once this is resolved, I'm worried about the next step -- the
>> definitions in the mailcap file refer to implementations of
>> DataHandlers (JAF interface) that are in a private package of
>> javax.mail.jar. I hope I'm wrong, but I suspect JAF will be unable
>> to access these classes to instantiate them. What is the solution?
>> Export those packages too? Even though they are supposed to be private?
>>
>> -Peter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>