Shouldn't any (exported?) resource in any bundle that the application
has access to be accessible to ClassLoader.getResource? Do we really
have to hardwire a set of resources we know about?
With the current scheme, are all resources in any jar file loaded
"above" the API class loader accessible through the context class
loader?
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
>