..taking this to -devel..
> fault. ClassLoader.getResource() does not look inside packages and will
> only find files at the root of classpath entries, unless the resource is
> specified with a path and that's something we currently can't do. There
> are ways around that (I just implemented a nifty solution that does 99% of
> what you want) but one obscure problem remains, so for the time being I
> recommend you put the config files where they work.
My nifty solution in ResourceLocator goes like this:
public static URL findURLInClassLoader(String name, ClassLoader loader) {
URL url = loader.getResource(name);
if (url == null) {
// try looking inside packages
Package[] packages = Package.getPackages();
for (int i = 0; i < packages.length; i++) {
Package p = packages[i];
String path = p.getName().replace('.', File.separatorChar)
+ File.separatorChar
+ name;
url = loader.getResource(path);
if (url != null) {
break;
}
}
}
return url;
}
Fast & works. This will find all files, no matter where they are, as long
as they are together somewhere on the classpath. Unfortunately it's only
99% correct: since users can pass their own classloaders for resource
finding, the above might not work properly since obviously the Package
class migth have been loaded from a different CL than the ResourceLocator.
Is it a reasonable assumption that the 'loader' instance could be used to
retrieve the packages list, in other words: does every ClassLoader have
access to at least the basic set of JDK classes? If that's the case,
loader.loadClass(Package.class.getName()) and some static reflection might
be the way to go here.
Package can also be used to dynamically locate subclasses & implementors
on the classpath, e.g. for plugins.
Holger
This archive was generated by hypermail 2.0.0 : Mon Feb 24 2003 - 22:54:49 EST