On Wed, Feb 16, 2011 at 5:16 PM, Mark Evenson evenson@panix.com wrote:
On 2/16/11 14:34 , Theam Yong Chew wrote: […]
Sorry Mark, I was going to add some more clarification to my original email, but you were too quick to reply! The above error message was actually slightly different from how I originally stumbled on the problem, which looked somewhat like this:
[1] CL-USER(1): (load "jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl") #<THREAD "interpreter" {12C9557}>: Debugger invoked on condition of type FILE-ERROR Loadable FASL not found for 'jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl' in 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._' Restarts: 0: ABORT Return to debug level 1.
[…]
So to clarify, it wasn't a "Failed to create URI" error, but a "Loadable FASL not found" error.
It looks like you might have encountered a more serious problem with our classloader. Can you mail me a copy of the failing jar file?
Notice the %2520 in the failing path: "in 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._'" It looks like something is URI-encoding the already-URI-encoded pathname, replacing the % in %20 with %25 (thus obtaining %2520). I don't think this has anything to do with the classloader, but I may be wrong here. Generally, we might need to distinguish between URI-escaping Pathname constructors (for strings coming from the outside world) and non-URI-escaping constructors for use by ABCL internals.
Bye, Alessio