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
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>