On 5/20/09 4:08 PM, Peter Williams wrote:
> Can you tell me why, even though JAF accessed a classloader that knew
> about javax.mail.jar, the file at META-INF/mailcap in that jar was not
> accessible. Is this because javax.mail.jar does not export META-INF?
> (I had problems attempting this, but I don't have the errors handy
> right now -- glassfish build issued a bunch of split package warnings
> though, I'm guessing because META-INF is present in all jars).
Exporting META-INF is not really a solution, since bundles can only be
wired to a given package once. So, you could connect your bundle to one
META-INF "package" by exporting it, but not all available ones, since
they would be seen as the same package.
I would guess it is not being seen because the situation is something
like this (I don't know the appropriate names):
* WebAppClassLoader has for its parent GFVirtualBundleClassLoader
* GFVirtualBundleClassLoader is a bundle class loader that has a
package wire for javax.mail to the javax.mail bundle.
The issue arises because the "wire" between GFVirtualBundleClassLoader
and the javax.mail bundle is based on a package name and requests are
only forwarded if they match the package name. Assuming the package name
is "javax.mail", then a resource request for "META-INF/foo" doesn't get
forwarded, while a request for "javax/mail/foo" does.
> Assuming the file can be located and processed though, it will contain
> fully qualified class names for the implementations of a particular
> public interface. The implementations will be in private packages of
> javax.mail.jar.
>
> Do you think JAF be able to instantiate these classes? If not,
> they'll need to be exported (e.g. public) too, correct?
Instantiating them is not an issue if you have a class loader (or use
Bundle.loadClass()), since the class loader of a bundle, by definition
can load anything to which its associated bundle has access. So, as long
as the class is actually public, it won't make a difference if it is
exported or not, when access the class loader directly.
> FWIW, it looks like another company (guess :)) using OSGi is having
> similar problems, as I ran across their (unresolved) bugs on this
> issue while research solutions.
Yes, the main approach for solving such situations is to use probing
(i.e, the extender model) as opposed to asking the context class loader.
-> richard
>
> Thanks
> -Peter
>
>>
>> This is a fairly common pattern in the JDK, and one we've recommended
>> in Java EE for quite a few years. This is essentially the same as
>> java.util.ServiceLoader.
>>
>> It's fine if an OSGi bundle has to explicitly export these classes so
>> they can be loaded by (e.g.) JAF, but JAF needs to be able to load these
>> classes using the context class loader.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>