Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0
-
None
-
None
-
Patch
Description
I have two scripts in a directory under C:\Documents and Settings:
A.groovy:
this.class.classLoader.loadClass("B", true, false, true)
and B.groovy which contains a simple (arbitrary) script.
A.groovy fails to find the "B" class. It gets as far as the GroovyClassLoader.getSourceFile, which successfully locates the resource URL "file:/C:/Documents%20and%20Settings/.../B.groovy". However, it then tries to turn this into a File on the line:
File path = new File(ret.getFile()).getParentFile();
This fails, as java.io.File expects the unescaped filename of "C:/Documents and Settings/...", i.e. with the %20s converted to spaces.
Attachments
Attachments
Issue Links
- is duplicated by
-
GROOVY-1833 blank in path makes calling one groovy file from another fail
- Closed
- is related to
-
GROOVY-1833 blank in path makes calling one groovy file from another fail
- Closed
I was able to reproduce this issue on my mac.
The patch file fixes the issue by safely decoding the file name by using the URLDecoder class. However, I did have to do a bit of a hack with the URLDecoder.UnsupportedEncodingException. If I am unable to decode the filename because of an UnsupportedEncodingException, I catch the exception and write an error out to the System Error. I then return the defaultFilePath passed into the method call. I did not want to throw this exception up especially since I am explicitly defining the encoding type into the call.
Also, I was unable to write a unit test that could reproduce this issue. I wrote one that I thought would work, but the unit test is passing even before I applied my change . However, I was able to manually unit test the code, reproduce the error before and after the fix and then validate that the fix worked after I applied the patch. Finally, I did re-run all unit tests to make sure I did not break the code.
I am attaching my attempt at the Unit test and if anyone can figure out what is going on with I would appreciate it. However, I would not commit the unit test to trunk until it actually works
Also, if anyone has any better solutions for the fix, feedback is welcome and I will be happy to try to work through it.