Yes, every "exported" resource is automatically available to Java EE
applications, but in this mailcaps file can't be exported as they don't
have a unique package name.
Yes, we follow delegation model, so resources from jars loaded above
"API Class Loader" are accessible through "Application Class Loader, "
which happens to be the context class loader during any request
processing or deployment activity. I am sure you noticed that the set of
such jars is limited to what is placed in java.ext.dirs, rt.jar and any
endorsed lib contents.
Thanks,
Sahoo
Bill Shannon wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>