Richard S. Hall wrote:
> 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.
Ok, that's pretty much what I guessed was going on here.
It sounds like you're telling me that with OSGi, files placed under
META-INF are complete inaccessible and there is nothing that can be done
to fix this (short of moving the files and/or rewriting the system that
works with them). Is this correct? (Aside: How do JDK services work then?)
I'm looking up this extender pattern you referred to. Am I right that
implementing it requires explicit dependencies on OSGi?
-Peter