<p>On 10-Mar-2011 3:58 PM, "Theam Yong Chew" <<a href="mailto:senatorzergling@gmail.com">senatorzergling@gmail.com</a>> wrote:<br>
><br>
> On 2/17/11, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br>
> > On Wed, Feb 16, 2011 at 5:16 PM, Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br>
> >> On 2/16/11 14:34 , Theam Yong Chew wrote:<br>
> >> […]<br>
> >>><br>
> >>> Sorry Mark, I was going to add some more clarification to my original<br>
> >>> email, but you were too quick to reply! The above error message was<br>
> >>> actually slightly different from how I originally stumbled on the<br>
> >>> problem, which looked somewhat like this:<br>
> >>><br>
> >>> [1] CL-USER(1): (load<br>
> >>> "jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl")<br>
> >>> #<THREAD "interpreter" {12C9557}>: Debugger invoked on condition of<br>
> >>> type FILE-ERROR<br>
> >>>    Loadable FASL not found for<br>
> >>> 'jar:file:/home/tyc20/Dropbox/temp/a%20space/hello.jar!/hello.abcl' in<br>
> >>> 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._'<br>
> >>> Restarts:<br>
> >>>    0: ABORT Return to debug level 1.<br>
> >>><br>
> >><br>
> >> […]<br>
> >><br>
> >>> So to clarify, it wasn't a "Failed to create URI" error, but a<br>
> >>> "Loadable FASL not found" error.<br>
> >>><br>
> >><br>
> >> It looks like you might have encountered a more serious problem with our<br>
> >> classloader.  Can you mail me a copy of the failing jar file?<br>
> ><br>
> > Notice the %2520 in the failing path: "in<br>
> > 'jar:jar:file:/home/tyc20/Dropbox/temp/a%2520space/hello.jar!/hello.abcl!/hello._'"<br>
> > It looks like something is URI-encoding the already-URI-encoded<br>
> > pathname, replacing the % in %20 with %25 (thus obtaining %2520).<br>
> > I don't think this has anything to do with the classloader, but I may<br>
> > be wrong here. Generally, we might need to distinguish between<br>
> > URI-escaping Pathname constructors (for strings coming from the<br>
> > outside world) and non-URI-escaping constructors for use by ABCL<br>
> > internals.<br>
> ><br>
> > Bye,<br>
> > Alessio<br>
><br>
> Hi everyone,<br>
><br>
> I had a quick look at the source over last week.  I'm not<br>
> completely confident if the attached patch fixes it, or if I've broken<br>
> anything else...  I'm also not sure if I'm running the unit tests<br>
> properly, but at least the number of failures hasn't gone up!<br>
><br>
> According to my understanding, truename already has some uriEncoding<br>
> logic in it (which I didn't quite follow), so it seemed to me like the<br>
> second uriEncode is the redundant culprit. Am I right?<br>
><br>
> Yong.</p>
<p>Hi everyone,</p>
<p>What's the effect of the latest Pathname.java work on this bug I reported a few months ago?</p>
<p>The one line patched I included then seemed to fix the loading of jar files with spaces in their pathnames, but then fails when loading .abcl files with spaces in their pathnames... so it still wasn't right.</p>
<p>I haven't been able to follow in detail (but I haven't looked too deeply) the pathname creation, defaulting of various fields and path  escaping logic myself. Any ideas on the right thing to do?</p>
<p>Yong.<br><br></p>