On 5/20/09 5:39 PM, Peter Williams wrote:
> 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?
It is not the case that they are completely inaccessible, they are just
not implicitly accessible. You can explicitly look for them if you want
to probe the installed bundles.
> (Aside: How do JDK services work then?)
In GF the extender pattern is used to probe installed bundles for
META-INF/services info. For generic info on the extender pattern, see:
http://www.osgi.org/blog/2007/02/osgi-extender-model.html
> I'm looking up this extender pattern you referred to. Am I right that
> implementing it requires explicit dependencies on OSGi?
The piece doing the probing would have explicit dependencies on OSGi,
but the providers wouldn't need to be dependent on OSGi.
-> richard
>
> -Peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>