Stefano Lenzi wrote:
Thomas Watson wrote:
I do not see a need to support this. A simple test shows that a
URLClassLoader loading jar files does not support this, although it
seems to work for URLs to a directory.
The OSGi Specification states that the Bundle.getResource(String)
behavior should be equal to the ClassLoader.getResource(String) which
on Sun JDK 6 update 1 (my configuration) it's able to resolve resource
containing '.' and '..'.
I don't think OSGi targets JDK 6... :-)
-> richard
The code which I used in tests is more or less the following:
package tests.resource;
import java.net.URL;
public class TestResourceLoading{
public static void main(String args[]){
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
URL url =
loader.getResource(".././resource/TestResourceLoading.class");
System.out.println("Loading "+url);
}
}
The javadoc for
ClassLoader.getResource also makes no mention that the resource name
can have relative resource path segments (e.g. '.' or '..') and that
the classloader must normalize the resource path when searching.
Did you mean that JavaDoc of ClassLoader.getResource(String) states
that the programmer must normalize the resource-path before invoking
the method? Because I've looked at the JavaDoc of ClassLoader and
ClassLoader.getResource(String) and I couldn't find any information
about that.
The
Bundle.getResource is pretty much an equivalent to
ClassLoader.getResource() method.
If you want to get a resource from a bundle which is relative to
another resource then you could use an initial URL as a context for a
relative URL like this:
URL initialResource = bundle.getResource("test/dir1/resource1.txt");
URL relativeResource = new URL(initialResource,
"../dir2/resource2.txt");
FWIW the equinox framwork does not support '.' or '..' segments in
resource names for Bundle.getResource either.
BTW, it's not a problem for me if we decide to do not support '.' or
'..' paths, at least we add some documentation or some entry in the FAQ.
Tom
Ciao,
Stefano Lenzi
