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 '..'.
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
