Richard S. Hall wrote:
> On 5/22/09 8:58 AM, Sahoo 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.
>>>
>> 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,
>
> I am fairly certain it is for classes only. From the documentation on
> the directives for Export-Package:
>
> "include – A comma-separated list of class names that must be visible to
> an importer. Note that the use of a comma in the value requires it to be
> enclosed in double quotes. For class filtering, see Class Filtering on
> page
> 46.
> exclude -A comma-separated list of class names that must be invisible to
> an importer. Note that the use of a comma in the value requires it to be
> enclosed in double quotes. For class filtering, see Class Filtering on
> page
> 46."
>
> From the class filtering section:
>
> "An exporter can limit the visibility of the classes in a package with
> the
> include and exclude directives on the export definition. The value of
> each of
> these directives is a comma-separated list of class names."
>
> The other notes that you mention could be a holdover from an earlier
> draft where we were considering resources.
>
> -> richard
>
>
I have filed a spec bug (#1330).
Thanks,
Sahoo