dev@glassfish.java.net

Re: How to make META-INF/mailcap visible to Java EE apps [Was: Re: OSGi confusion...]

From: Sahoo <Sahoo_at_Sun.COM>
Date: Fri, 22 May 2009 18:28:55 +0530

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.
>
Hmmm. Is this mentioned anywhere in the spec? Although the section is
titled as "Class Filtering," it does talk about resource filtering as
shown below:

/The default for the include directive is * (wildcard matching all
names), and for the exclude directive, so that no classes or *resources*
are excluded, an empty list that matches no names./
...
/Care must be taken when using filters. For example, a new version of a
module that is intended to be backward compatible with an earlier
version should not filter out classes or *resources* that were not
filtered out by the earlier version. In addition, when modularizing
existing code, filtering out classes or *resources* from an exported
package may break users of the pack-age.

/Thanks,
Sahoo