Stefano Lenzi <[EMAIL PROTECTED]> wrote on 09/18/2007 07:06:58 AM:
> 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 '..'.
Are you running this code within an IDE where the classes are loaded out
of an output folder instead of a JAR file? When I test on JDK 6 relative
paths do not work for JARs. I suspect directory classpaths within the IDE
work because the URLClassloader simply creates File objects with the path
which do the normalization for them but JarFile.getEntry does not
handle normalization for jars.
>
> 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");
What does ../. indicate here for a classloader? Go up one directory from
what reference point? In an OSGi environment this would be meaningless
because the location of the bundle classpath content is not exposed and
cannot be used as a reference point for the relative paths.
> 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.
I mean the JavaDoc for ClassLoader.getResource(String). It does not
make it clear that the ClassLoader implementation must perform
normalization on the given resource path. In many classloaders
relative paths do not make sense because there is no good reference
point for the "root" of the classloader to base relative paths off of.
Tom
