getResource*() should follow exactly the same rules as classloading. You
have not considered Require-Bundle or parent classloaders. This can
result in resources from many bundles (split packages). Take a look at
BundleLoader.findResources(String) in the reference implementation. It
enumerates the steps for finding resources.
Jeff
Olivier Gruber <[EMAIL PROTECTED]>
09/22/2006 05:59 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Bundle.getResources
I am implementing the Bundle.getResources(String)
and I want to confirm something.
Assuming the bundle is resolved, we are looking in
- its imports
- its local class path
- we retry to satisfy dynamic imports in case it would yield
something.
So that's all fine. Now the tricky question: if we find something from an
import,
should we continue or not? I believe we should not continue, here is why.
If it is found from an import, this means that the resource is from a Java
package
(otherwise, it would not be found as part of an import). It seems to me
that we want
a consistent behavior with class loading. If a class is search for and its
package
is an import, we do not look in the local class path in case of failure
loading from
the import.
So I have implemented getResources in the same way.
If it finds that the path to the resource is an imported package, it will
attempt
loading from this import. If it succeeds, it stops there, the local class
path
is not considered. The import has or has no corresponding resources (0,1,
or more).
If it does not match an imported package, the local class path is
search and 0,1 or more resource may be found locally.
Another way to say this is that all the various resources found will be
from a single bundle. Either they will be local resources, solely from
this
bundle on which we called getResources(). Or the resources will be
solely from the bundle used to satisfy the import of the corresponding
package.
It all depends if the path to the resources is an imported package or not.
Comments?
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
