felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Gruber <ogru...@us.ibm.com>
Subject Re: Bundle.getResources
Date Fri, 22 Sep 2006 16:12:21 GMT
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" <heavy@ungoverned.org> 
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 <ogruber@us.ibm.com> 
> 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
>
>
>
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message