I think such code will be very useful for things like locating DbAdapter
implementations and/or JDBC driver implementations in the outside jar
files in the Modeler. But scanning all packages to locate project
configuration file (cayenne.xml) seems a bit risky and adds
non-deterministic factor to an already convoluted CLASSPATH/ClassLoader mix.
Andrus
Holger Hoffstätte wrote:
> ..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.
This archive was generated by hypermail 2.0.0 : Tue Feb 25 2003 - 00:50:04 EST