cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: [C2 ClassLoading] RepositoryClassLoader - possible faults
Date Tue, 19 Dec 2000 11:59:34 GMT
Sorry, slight correction...

getCanonicalPath() works fine, but toURL doesn't use it and does not resolve "../" path components
automatically. This appears to be in contradiction with the 1.3 spec:

> The path is canonicalized through the removal of directory changes made by occurences
of 
> ".." and ".". For a more detailed description of URL parsing, refer to RFC2396. 

But, now of the good news...

If you change the line:

          this.addURL(repository.toURL());

in the addDirectory(File) method of RepositoryClassLoader.java, to:

          this.addURL(repository.getCanonicalFile().toURL());

*everything works*

yes, you've read me correctly, it doesn't just fix the URLs, it fixes *everything*

Yes, yes, yes, yes...
Diddly, dumpty, dumpty, dee...
Yipee, at last

Stuart.

(Apologies if I appear uncontrollably happy!)


On Tuesday, December 19, 2000, at 11:33 AM, Stuart Roebuck wrote:

> In my every ongoing task of trying to get C2 working, I have been learning about 
> classloaders, and have spotted two things along the way that may be relevant: 
>  
> 1. java.io.File.getCanonicalPath() is broken on Java 1.2.?  I've noted the odd message

> on the net from other people with the same fault so this isn't unique to MacOS X.  Whilst

> getCanonicalPath doesn't guarantee to produce a platform independent path, it implies

> (as the name 'canonical' does) that the same path will always results in the same 
> Canonical Path on a single machine.  However, currently it neither produces the 
> 'absolute' path it is supposed to, nor does it resolve "../" path components.  This fault

> is also exhibited in the resulting File.getURL() method used by the current classloader

> mechanism in Cocoon. getURL does produce an absolute path, but doesn't resolve "../"

> path components. 
>  
> 2. There appears to be no code in the current classloader to prevent multiple duplicate

> URLs being added o a single URLClassLoader instance.  I discovered this when I printed
out 
> the result of a getURLs() method call and found three identical classpaths.  This may
not 
> cause any faults, but it certainly doesn't look like an efficient mechanism in the 
> long-run. 
>  
>  
> If point 1 is fixed on 1.3 this might be related to the faults only some people are 
> experiencing with the current classloader. 
>  
>  
> Stuart. 
>  
> ------------------------------------------------------------------------- 
> Stuart Roebuck                                  stuart.roebuck@adolos.com 
> Lead Developer                                  Mac OS X, Java, XML, etc. 
> ADOLOS                                             http://www.adolos.com/ 
>  


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                                  Mac OS X, Java, XML, etc.
ADOLOS                                             http://www.adolos.com/
Mime
View raw message