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 > > > >
