You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stefano Lenzi <ki...@interfree.it> on 2007/09/17 22:17:33 UTC
A bug in Bundle.getResource(String)?
Hi All,
I've found a odd behavior in the method Bundle.getResource(String), the
method is not able to resolve the resource if the reource path contains:
'.' or '..' directory.
I have already patched the:
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getResource(String)
in order to accept the '..' and '.' path (see attchment).
Can I commit the patch?
Ciao,
Stefano "Kismet" Lenzi
P.S.: As you can see from my patch I do not consider the case when the
URL is encoded.
P.P.S.: Should I report a issue on JIRA?
Re: A bug in Bundle.getResource(String)?
Posted by Stefano Lenzi <ki...@interfree.it>.
Richard S. Hall wrote:
> I am not convinced we want to support this. Is this standard class
> loader behavior?
>
> i.e., would URLClassLoader.getResource() support that syntax?
I have just made some test both:
- Class.getResource(String path)
- ClassLoader.getResource(String path)
on Java resolve path containing '.' and '..' directory, but none of them
perform URL decoding.
Ciao,
Stefano "Kismet" Lenzi
>
> -> richard
Re: A bug in Bundle.getResource(String)?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I am not convinced we want to support this. Is this standard class
loader behavior?
i.e., would URLClassLoader.getResource() support that syntax?
-> richard
Stefano Lenzi wrote:
> Hi All,
>
> I've found a odd behavior in the method Bundle.getResource(String),
> the method is not able to resolve the resource if the reource path
> contains: '.' or '..' directory.
>
> I have already patched the:
> org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getResource(String)
>
> in order to accept the '..' and '.' path (see attchment).
>
> Can I commit the patch?
>
>
> Ciao,
> Stefano "Kismet" Lenzi
>
> P.S.: As you can see from my patch I do not consider the case when the
> URL is encoded.
>
> P.P.S.: Should I report a issue on JIRA?
>
>
Re: A bug in Bundle.getResource(String)?
Posted by Marcel Offermans <ma...@luminis.nl>.
On Sep 18, 2007, at 16:21 , Richard S. Hall wrote:
> Stefano Lenzi wrote:
>> 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... :-)
That's not really the point. If the spec refers to the Java
specifications, it should then be more specific about what version,
if it intended not to follow the current Java specifications.
Greetings, Marcel
Re: A bug in Bundle.getResource(String)?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: A bug in Bundle.getResource(String)?
Posted by Stefano Lenzi <ki...@interfree.it>.
Richard S. Hall wrote:
> Stefano Lenzi wrote:
>> OK! So it semms we can close the issue, because it's not a bug but the
>> *OSGi standard* behavior.
>
> Sorry if it seems like we were beating you down...we tend to debate
> vigorously in CPEG... ;-)
>
> Always worthwhile to discuss the issues, though.
No problem :) Fighting is part of the game :P
BTW, Thinking on issue let you learn ^_^
Ciao,
Stefano "Kismet" Lenzi
P.S.: In any case the '.' or '..' could be a good entry for a
troubleshooting FAQ :)
>
> -> richard
>
>
Re: A bug in Bundle.getResource(String)?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stefano Lenzi wrote:
> OK! So it semms we can close the issue, because it's not a bug but the
> *OSGi standard* behavior.
Sorry if it seems like we were beating you down...we tend to debate
vigorously in CPEG... ;-)
Always worthwhile to discuss the issues, though.
-> richard
Re: A bug in Bundle.getResource(String)?
Posted by Stefano Lenzi <ki...@interfree.it>.
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 {@link #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
Re[2]: A bug in Bundle.getResource(String)?
Posted by Peter Kriens <Pe...@aQute.biz>.
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 {@link #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 <ki...@interfree.it> 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
Re: A bug in Bundle.getResource(String)?
Posted by Thomas Watson <tj...@us.ibm.com>.
Stefano Lenzi <ki...@interfree.it> 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
Re: A bug in Bundle.getResource(String)?
Posted by Stefano Lenzi <ki...@interfree.it>.
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
Re: A bug in Bundle.getResource(String)?
Posted by Thomas Watson <tj...@us.ibm.com>.
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 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. 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.
Tom
"Karl Pauls"
<karlpauls@gmail.
com> To
dev@felix.apache.org
09/17/2007 03:46 cc
PM
Subject
Re: A bug in
Please respond to Bundle.getResource(String)?
dev@felix.apache.
org
Hi Stefano,
please create a JIRA issue and attach your patch there. I'm currently
busy preparing the 1.0.1 release and this will have to wait until we
have it out of the door.
regards,
Karl
> Hi All,
>
> I've found a odd behavior in the method Bundle.getResource(String), the
> method is not able to resolve the resource if the reource path contains:
> '.' or '..' directory.
>
> I have already patched the:
>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getResource(String)
> in order to accept the '..' and '.' path (see attchment).
>
> Can I commit the patch?
>
>
> Ciao,
> Stefano "Kismet" Lenzi
>
> P.S.: As you can see from my patch I do not consider the case when the
> URL is encoded.
>
> P.P.S.: Should I report a issue on JIRA?
>
>
>
> Index:
src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java
> ===================================================================
> ---
src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java
(revision 576472)
> +++
src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java
(working copy)
> @@ -22,12 +22,18 @@
> import java.io.InputStream;
> import java.net.URL;
> import java.security.ProtectionDomain;
> +import java.util.ArrayList;
> import java.util.Enumeration;
> +import java.util.Iterator;
> +import java.util.StringTokenizer;
> import java.util.Vector;
>
> import org.apache.felix.framework.Logger;
> import org.apache.felix.framework.util.SecureAction;
> -import org.apache.felix.moduleloader.*;
> +import org.apache.felix.moduleloader.IContent;
> +import org.apache.felix.moduleloader.IContentLoader;
> +import org.apache.felix.moduleloader.ISearchPolicy;
> +import org.apache.felix.moduleloader.IURLPolicy;
>
> public class ContentLoaderImpl implements IContentLoader
> {
> @@ -129,13 +135,49 @@
> public URL getResource(String name)
> {
> URL url = null;
> -
> +
> + //TODO Handling encoded URL
> +
> // Remove leading slash, if present.
> if (name.startsWith("/"))
> {
> name = name.substring(1);
> - }
> -
> + }
> +
> + /*
> + * NORMALIZING PATH:
> + * 1 - Removing /./ path
> + * 2 - Resolving /../ path
> + */
> + StringTokenizer tokenizer = new StringTokenizer(name,"/");
> + ArrayList parts = new ArrayList();
> + while(tokenizer.hasMoreTokens())
> + {
> + String namePart = tokenizer.nextToken();
> + if(namePart.equals("."))
> + {
> + continue;
> + }
> + else if(namePart.equals("..") && parts.size()>=1)
> + {
> + //XXX Should we launch an exception if
there are too many parent directory?!?!?
> + parts.remove(parts.size()-1);
> + }
> + else
> + {
> + parts.add(namePart);
> + }
> + }
> +
> + //Rebuilding the path from parts
> + name = "";
> + for (Iterator i = parts.iterator(); i.hasNext();)
> + {
> + String p = (String) i.next();
> + name += "/" + p;
> + }
> + name = name.substring(1);
> +
> // Check the module class path.
> for (int i = 0;
> (url == null) &&
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: A bug in Bundle.getResource(String)?
Posted by Karl Pauls <ka...@gmail.com>.
On 9/17/07, Stefano Lenzi <ki...@interfree.it> wrote:
> Karl Pauls wrote:
> > Hi Stefano,
> >
> > please create a JIRA issue and attach your patch there. I'm currently
> > busy preparing the 1.0.1 release and this will have to wait until we
> > have it out of the door.
>
> Does it mean that the codebase for apache felix is frozen?
More or less, I'm hoping to call a vote asap.
> Do you want to me apply the patch for 1.0.2-SNAPSHOT codebase?
Well, just wait until I created a branch for the release. Also, did
you see Richards comment? I think I agree with him so you might want
to argue your case first :-)
regards,
Karl
> > regards,
> >
> > Karl
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: A bug in Bundle.getResource(String)?
Posted by Stefano Lenzi <ki...@interfree.it>.
Karl Pauls wrote:
> Hi Stefano,
>
> please create a JIRA issue and attach your patch there. I'm currently
> busy preparing the 1.0.1 release and this will have to wait until we
> have it out of the door.
Does it mean that the codebase for apache felix is frozen?
Do you want to me apply the patch for 1.0.2-SNAPSHOT codebase?
>
> regards,
>
> Karl
Re: A bug in Bundle.getResource(String)?
Posted by Karl Pauls <ka...@gmail.com>.
Hi Stefano,
please create a JIRA issue and attach your patch there. I'm currently
busy preparing the 1.0.1 release and this will have to wait until we
have it out of the door.
regards,
Karl
> Hi All,
>
> I've found a odd behavior in the method Bundle.getResource(String), the
> method is not able to resolve the resource if the reource path contains:
> '.' or '..' directory.
>
> I have already patched the:
> org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getResource(String)
> in order to accept the '..' and '.' path (see attchment).
>
> Can I commit the patch?
>
>
> Ciao,
> Stefano "Kismet" Lenzi
>
> P.S.: As you can see from my patch I do not consider the case when the
> URL is encoded.
>
> P.P.S.: Should I report a issue on JIRA?
>
>
>
> Index: src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java
> ===================================================================
> --- src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java (revision 576472)
> +++ src/main/java/org/apache/felix/framework/searchpolicy/ContentLoaderImpl.java (working copy)
> @@ -22,12 +22,18 @@
> import java.io.InputStream;
> import java.net.URL;
> import java.security.ProtectionDomain;
> +import java.util.ArrayList;
> import java.util.Enumeration;
> +import java.util.Iterator;
> +import java.util.StringTokenizer;
> import java.util.Vector;
>
> import org.apache.felix.framework.Logger;
> import org.apache.felix.framework.util.SecureAction;
> -import org.apache.felix.moduleloader.*;
> +import org.apache.felix.moduleloader.IContent;
> +import org.apache.felix.moduleloader.IContentLoader;
> +import org.apache.felix.moduleloader.ISearchPolicy;
> +import org.apache.felix.moduleloader.IURLPolicy;
>
> public class ContentLoaderImpl implements IContentLoader
> {
> @@ -129,13 +135,49 @@
> public URL getResource(String name)
> {
> URL url = null;
> -
> +
> + //TODO Handling encoded URL
> +
> // Remove leading slash, if present.
> if (name.startsWith("/"))
> {
> name = name.substring(1);
> - }
> -
> + }
> +
> + /*
> + * NORMALIZING PATH:
> + * 1 - Removing /./ path
> + * 2 - Resolving /../ path
> + */
> + StringTokenizer tokenizer = new StringTokenizer(name,"/");
> + ArrayList parts = new ArrayList();
> + while(tokenizer.hasMoreTokens())
> + {
> + String namePart = tokenizer.nextToken();
> + if(namePart.equals("."))
> + {
> + continue;
> + }
> + else if(namePart.equals("..") && parts.size()>=1)
> + {
> + //XXX Should we launch an exception if there are too many parent directory?!?!?
> + parts.remove(parts.size()-1);
> + }
> + else
> + {
> + parts.add(namePart);
> + }
> + }
> +
> + //Rebuilding the path from parts
> + name = "";
> + for (Iterator i = parts.iterator(); i.hasNext();)
> + {
> + String p = (String) i.next();
> + name += "/" + p;
> + }
> + name = name.substring(1);
> +
> // Check the module class path.
> for (int i = 0;
> (url == null) &&
>
>
--
Karl Pauls
karlpauls@gmail.com