Where in this Javadoc do you find -anything- about relative paths or .
for current directory? The only thing it says that the path name is /
separated. I do not think that because there are file systems that
accept a . and .. you can imply that this should also support relative
paths ...
/**
* Finds the resource with the given name. A resource is some data
* (images, audio, text, etc) that can be accessed by class code in a way
* that is independent of the location of the code.
*
* <p> The name of a resource is a '<tt>/</tt>'-separated path name that
* identifies the resource.
*
* <p> This method will first search the parent class loader for the
* resource; if the parent is <tt>null</tt> the path of the class loader
* built-in to the virtual machine is searched. That failing, this method
* will invoke [EMAIL PROTECTED] #findResource(String)} to find the
resource. </p>
*
* @param name
* The resource name
*
* @return A <tt>URL</tt> object for reading the resource, or
* <tt>null</tt> if the resource could not be found or the invoker
* doesn't have adequate privileges to get the resource.
*
* @since 1.1
*/
Too see the difference, look at the Javadoc for URLs:
* Otherwise, the path is treated as a relative path and is appended to the
* context path, as described in RFC2396. Also, in this case,
* the path is canonicalized through the removal of directory
* changes made by occurences of ".." and ".".
Kind regards,
Peter Kriens
TW> 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 '..'.
TW> Are you running this code within an IDE where the classes are loaded out
TW> of an output folder instead of a JAR file? When I test on JDK 6 relative
TW> paths do not work for JARs. I suspect directory classpaths within the IDE
TW> work because the URLClassloader simply creates File objects with the path
TW> which do the normalization for them but JarFile.getEntry does not
TW> 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");
TW> What does ../. indicate here for a classloader? Go up one directory from
TW> what reference point? In an OSGi environment this would be meaningless
TW> because the location of the bundle classpath content is not exposed and
TW> 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
TW> 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.
TW> I mean the JavaDoc for ClassLoader.getResource(String). It does not
TW> make it clear that the ClassLoader implementation must perform
TW> normalization on the given resource path. In many classloaders
TW> relative paths do not make sense because there is no good reference
TW> point for the "root" of the classloader to base relative paths off of.
TW> Tom
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
