On 5/22/09 5:58 PM, Bill Shannon wrote:
> Richard S. Hall wrote:
>> On 5/22/09 1:22 AM, Sahoo wrote:
>>> Bill Shannon wrote:
>>>> Sahoo wrote:
>>>>> 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.
>>>>
>>>> It's a resource, not a class. Resources don't necessarily have a
>>>> package
>>>> name. Can't I export a single resource file?
>>> Yes, I understand it's a resource. AFAIK, OSGi treats resources like
>>> classes, so if a bundle wants to make available a resource called
>>> a/b/c.properties, then it has to export package a.b and a bundle
>>> that want to use the resource has to import package a.b. You can
>>> export a single resource just like you can export a single class of
>>> a package using a technique called "Class Filtering," but there also
>>> you have to first export the package and reduce the set of visible
>>> classes by suitable use of an attribute.
>>>
>>> The problem in case of META-INF/mailcap is that it does not have a
>>> unique namespace. More over, you want visibility to
>>> META-INF/mailcap files available in all OSGi bundle, not just one
>>> bundle where as Import-Package will wire the importer to one bundle
>>> only.
>>
>> Yes, this is all true except that class filtering does not apply to
>> resources, only classes. So there is no way to further restrict the
>> set of resources exported from a given package.
>
> If I have an OSGi bundle and I want to export all my resources in
> META-INF, I should export the "package" META-INF? There's no way
> to export an individual resource?
Conceptually, you are correct, but in practice that really doesn't make
a lot of sense in pure OSGi since in this model you want to be able to
see more than one (or all) META-INF "packages", but a bundle importing
"META-INF" will only be able to see it from one bundle.
This is why the extender pattern is used here, since it probes all
META-INF directories, which is what you want.
> I'm assuming that all resources in any non-OSGi jar file that's
> packaged with my application will be available via the application
> class loader, right? So the issue is only with OSGi bundles deployed
> "below" the application class loader?
That is my understanding.
-> richard