Community
Participate
Working Groups
Build Identifier: A BundleDelegatingClassLoader can optionally be created with a fallback class loader in addition to referencing a bundle. e.g. ClassLoader bl = BundleDelegatingClassLoader.createBundleClassLoaderFor(bundle, bridge); getResource is overridden in BundleDelegatingClassLoader to look first in the bundle (by calling findResource, which only looks in the bundle), then if the resource is not found, to ask the fallback class loader. getResources does not work in the same way. This method is *not* overridden in BundleDelegatingClassLoader, and the implementation inherited from java.lang.ClassLoader uses findResources. The findResources method in BundleDelegatingClassLoader only looks at the bundle - it does not include any resources found from the fallback class loader. A workaround is to create a subclass of BundleDelegatingClassLoader with an overridden findResources method, that in addition to getting resources from the bundle, also gets resources from the fallback class loader (if one has been specified). Reproducible: Always Steps to Reproduce: 1. Construct BundleDelegatingClassLoader with a fallback class loader 2. Call getResources with the name of a resource not in the bundle, but which can be found by the fallback class loader
BundleDelegatingClassLoader source, for reference: http://git.eclipse.org/c/gemini.blueprint/org.eclipse.gemini.blueprint.git/tree/core/src/main/java/org/eclipse/gemini/blueprint/util/BundleDelegatingClassLoader.java
This is a restriction in the current implementation, but is something we could consider implementing in future as the desired behaviour seems reasonable. I won't have time to implement this personally, but I would consider a patch for a major version of Gemini Blueprint. The new behaviour would need testing with Virgo however as we don't want to wreck Virgo's resource lookup behaviour. I hope to ship Gemini Blueprint 2.0 this quarter, so if anyone who reads this is interested in developing a patch soon, that would be great.
(In reply to comment #2) > The new behaviour would need testing with Virgo however as we don't want to > wreck Virgo's resource lookup behaviour. I am wondering what the behavior should be in this case. Normally, the the method will just return an empty enum if no matching resources are found - so there are two options: 1.) Return the result of bridge.getResources if the enumeration provided by the original classloader is empty 2.) Return an enumeration representing the contents of both the current and the bridge classloader I have a tendency towards the latter solution as it better represents the resources actually available in the BundleDelegatingClassLoader.
(In reply to comment #3) > (In reply to comment #2) > > > The new behaviour would need testing with Virgo however as we don't want to > > wreck Virgo's resource lookup behaviour. > > I am wondering what the behavior should be in this case. Normally, the the > method will just return an empty enum if no matching resources are found - > so there are two options: > > 1.) Return the result of bridge.getResources if the enumeration provided by > the original classloader is empty > > 2.) Return an enumeration representing the contents of both the current and > the bridge classloader > > I have a tendency towards the latter solution as it better represents the > resources actually available in the BundleDelegatingClassLoader. Agreed, but the overall resource loading in Virgo is too complex for me to hold in my head, so we'd need to test this. Are you thinking of providing a patch for 2.0?
Created attachment 228701 [details] Patch extending the resource retrieval to both backing bundle and bridge classloader Yes :-) I have added a patch that will combine the resources from the backing bundle and the bridge into one enumeration. The changed tested successfully with all integration profiles. I have also provided a unit test covering the use cases.
Thanks for the patch. I'm afraid I need to ask you the same questions again - did you author 100% of the patch and have your the rights to commit it? (Please note that the Eclipse Foundation are planning some improvements to make repeated contributions simpler. I'd post a link, but couldn't find one.)
(In reply to comment #6) > Thanks for the patch. I'm afraid I need to ask you the same questions again > - did you author 100% of the patch and have your the rights to commit it? > > (Please note that the Eclipse Foundation are planning some improvements to > make repeated contributions simpler. I'd post a link, but couldn't find one.) No problem: I hereby confirm that I am the author of the contribution and have the right to commit it.
Committed as bdddfe8298f1c60ffc54098fe7bb98d9d63e3ff8.
I should have said, I reserve the right to revert this commit if it regresses Virgo.
I have upgraded Virgo master (destined for 3.7.0) to Gemini Blueprint 2.2.0.M02, and all the tests pass.
