I can agree with this.
-> richard
Olivier Gruber wrote:
The parent class loader was done, I just forgot to mention it.
Indeed, I was not mention require-bundle and split-packages
because neither are an issue in Felix as of now.
Therefore, I maintain that we should follow the semantics of classloading
and therefore have imports shadowing local class path. In other words,
we get the resources either from a corresponding import or from the local
class path.
I will submit a patch in the corresponding JIRA.
Best regards,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"If at first the idea is not absurd, then there is no hope for it."
Albert Einstein
"Richard S. Hall" <[EMAIL PROTECTED]>
09/22/2006 04:15 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Bundle.getResources
Well, we have not implemented require-bundle yet, which is why he is
probably not considering that, but you are right. I too was going to
point out parent class loaders...
-> richard
Jeff McAffer wrote:
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
