WenFAN / reflections

Automatically exported from code.google.com/p/reflections
Do What The F*ck You Want To Public License
0 stars 0 forks source link

Error when white space in the paths #99

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When the path contains a plus-sign then the scanning for jars is broken.

I have an application scanning dynamic loaded jars for annotated classes. If 
the install-path contains a plus (e.g. d:/N+P) then the following error occurs:

26.01.12 08:57 ERROR could not create Vfs.Dir from url. ignoring the exception 
and continuing [org.reflections.Reflections]
org.reflections.ReflectionsException: could not create Dir using jarfile from 
url file:/D:/N+P/server/bin/../plugins/de_nupis_spartacus_inventur_server.jar
        at org.reflections.vfs.Vfs.fromURL(Vfs.java:98)
        at org.reflections.vfs.Vfs.fromURL(Vfs.java:88)
        at org.reflections.Reflections.scan(Reflections.java:226)
        at org.reflections.Reflections.<init>(Reflections.java:104)
        at de.nupis.kernel.nachrichten.Nachrichtenzentrale.initMethodHandlers(Nachrichtenzentrale.java:282)
        at de.nupis.kernel.nachrichten.Nachrichtenzentrale.init(Nachrichtenzentrale.java:59)
        at de.nupis.kernel.Start.starteServer(Start.java:342)
        at de.nupis.kernel.Start.starteKernel(Start.java:115)
        at de.nupis.kernel.Start.main(Start.java:1506)
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: D:\N 
P\server\bin\..\plugins\de_nupis_spartacus_inventur_server.jar (Das System kann 
den angegebenen Pfad nicht finden)
        at org.reflections.vfs.ZipDir.<init>(ZipDir.java:23)
        at org.reflections.vfs.Vfs$DefaultUrlTypes$1.createDir(Vfs.java:153)
        at org.reflections.vfs.Vfs.fromURL(Vfs.java:96)
        ... 8 more
Caused by: java.io.FileNotFoundException: D:\N 
P\server\bin\..\plugins\de_nupis_spartacus_inventur_server.jar (Das System kann 
den angegebenen Pfad nicht finden)
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at org.reflections.vfs.ZipDir.<init>(ZipDir.java:22)
        ... 10 more

This occurs on windows server 2008R2 but I think this will occur on every 
operating system.

Original issue reported on code.google.com by dirk.zie...@gmail.com on 26 Jan 2012 at 9:02

GoogleCodeExporter commented 8 years ago
I've noticed a similar issue on files who's URL path contains spaces encoded as 
'%20' (windows 7 64 bit); one thing I've noticed is that passing the full URL 
path into a java.io.File constructor resolves to a java.io.File at the proper 
location;
but stripping off the 'file:' protocol and passing it into 
java.util.zip.ZipFile's constructor does not.

So this problem might be resolved within ZipDir's constructor by constructing a 
java.io.File object from the 'file:' URL, and using that file object as input 
to the 
java.util.zip.ZipFile constructor, perhaps something like this:

public ZipDir(String p) {
    path = p;
    if (path.startsWith("jar:")) { path = path.substring("jar:".length()); }
    if (path.endsWith("!/")) { path = path.substring(0, path.lastIndexOf("!/")) + "/"; }
    try {
        if (path.startsWith("file:")) { 
            zipFile = new java.util.zip.ZipFile(new java.io.File(path));
        } else {
            zipFile = new java.util.zip.ZipFile(this.path); 
        }
    } catch (IOException e) {throw new RuntimeException(e);}
}
sorry, I haven't had a cance to confirm this yet...

Original comment by matt.deb...@gmail.com on 16 Feb 2012 at 1:20

GoogleCodeExporter commented 8 years ago
Hi I had the same problem on Win7 64bit. I tried the above fix and with a minor 
addition: changed the ZipDir(URL) constructor with a code from an older version 
of this class.

  public ZipDir(URL url) {
    //issue#99 ---
    // this(url.getPath());
    //------
    this(Vfs.normalizePath(url));
  }

  public ZipDir(String p) {
    this.path = p;
    if (this.path.startsWith("jar:")) {
      this.path = this.path.substring("jar:".length());
    }
    //issue#99 ---
    // if (path.startsWith("file:")) {
    // path = path.substring("file:".length());
    // }
    //---------
    if (this.path.endsWith("!/")) {
      this.path = this.path.substring(0, this.path.lastIndexOf("!/")) + "/";
    }

    try {
      //issue#99 ---
      // zipFile = new java.util.zip.ZipFile(this.path);
      // fix:
      if (this.path.startsWith("file:")) {
        this.zipFile = new java.util.zip.ZipFile(new java.io.File(this.path));
      } else {
        this.zipFile = new java.util.zip.ZipFile(this.path);
      }
      // ---
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }

The above code works for me. Could you please check if this passes all tests of 
the project.
I am using this module in a production environment for a dynamic module 
management component and this problem is quite annoying since it does not allow 
the execution of the whole application we built, from a path having spaces in 
it.
Thanks in advance.

Original comment by norbert....@gmail.com on 21 Feb 2012 at 10:16

Attachments:

GoogleCodeExporter commented 8 years ago
fixed on 0.9.7-RC1 and trunk. comments?

Original comment by ronm...@gmail.com on 2 May 2012 at 3:50

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Tested and verified. Seems to work :)

Original comment by dirk.zie...@gmail.com on 7 May 2012 at 10:29

GoogleCodeExporter commented 8 years ago
Is there a workaround for this issue? I'm on 0.9.5 and am hitting this when 
using the <java> ant tag in Windows (it barfs on 
file:/C:/Program%20Files/Java/jdk1.6.0_23/lib/tools.jar).

I'm using setUrls(ClasspathHelper.forJavaClassPath()) at the moment, but could 
we do some sort of processing on the URLs this returns to change the 
problematic URLs? I've also tried adding a default UrlType to handle 'file' 
URLs but it isn't being picked up.

Original comment by jty...@gmail.com on 18 May 2012 at 1:57

GoogleCodeExporter commented 8 years ago
fixed 0.9.7

Original comment by ronm...@gmail.com on 22 May 2012 at 7:47