Peter Kriens wrote:
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
OK! So it semms we can close the issue, because it's not a bug but the *OSGi standard* behavior.
Ciao, Stefano "Kismet" Lenzi
