Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Subject: RE: [C2 ClassLoading] RepositoryClassLoader - possible faults
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Dec 2000 10:11:09 -0600
Message-ID: <FDB7E4EEFF526C4B83502D8FB3B6DE48014734@zephyr.olrcorp.com>
content-class: urn:content-classes:message
Thread-Topic: [C2 ClassLoading] RepositoryClassLoader - possible faults
Thread-Index: AcBpv4ClyCsRuaOXQvOf0iqJZDpwnQAFngUw
From: "Paul Lamb" <paul@oil-law.com>
To: <cocoon-dev@xml.apache.org>

Thanks for figuring this out. I just tried this with the latest Catalina
and jdk 1.3.0_01 and c2 seems to work great again.

Paul Lamb

-----Original Message-----
From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
Sent: Tuesday, December 19, 2000 7:28 AM
To: cocoon-dev@xml.apache.org
Subject: Re: [C2 ClassLoading] RepositoryClassLoader - possible faults


A little follow up to this...

Of my original points (down below), point 2 is solved automatically by
the fix immediately below.  It looks like addURL assumes canonical URLs
when its comparing new entries.

Secondly, there are a number of uses of toURL scattered around Cocoon -
I wonder whether it may be worth folk familiar with the code checking
whether those toURL method calls would also benefit from this bug fix.

Stuart.


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

> Sorry, slight correction...=20
> =20
> getCanonicalPath() works fine, but toURL doesn't use it and does not
resolve "../" path=20
> components automatically. This appears to be in contradiction with the
1.3 spec:=20
> =20
> > The path is canonicalized through the removal of directory changes
made by occurences=20
> of =20
> > ".." and ".". For a more detailed description of URL parsing, refer
to RFC2396. =20
> =20
> But, now of the good news...=20
> =20
> If you change the line:=20
> =20
>           this.addURL(repository.toURL());=20
> =20
> in the addDirectory(File) method of RepositoryClassLoader.java, to:=20
> =20
>           this.addURL(repository.getCanonicalFile().toURL());=20
> =20
> *everything works*=20
> =20
> yes, you've read me correctly, it doesn't just fix the URLs, it fixes
*everything*=20
> =20
> Yes, yes, yes, yes...=20
> Diddly, dumpty, dumpty, dee...=20
> Yipee, at last=20
> =20
> Stuart.=20
> =20
> (Apologies if I appear uncontrollably happy!)=20
> =20
> =20
> On Tuesday, December 19, 2000, at 11:33 AM, Stuart Roebuck wrote:=20
> =20
> > In my every ongoing task of trying to get C2 working, I have been
learning about =20
> > classloaders, and have spotted two things along the way that may be
relevant: =20
> >  =20
> > 1. java.io.File.getCanonicalPath() is broken on Java 1.2.?  I've
noted the odd message =20
> > on the net from other people with the same fault so this isn't
unique to MacOS X.  Whilst =20
> > getCanonicalPath doesn't guarantee to produce a platform independent
path, it=20
> implies =20
> > (as the name 'canonical' does) that the same path will always
results in the same =20
> > Canonical Path on a single machine.  However, currently it neither
produces the =20
> > 'absolute' path it is supposed to, nor does it resolve "../" path
components.  This fault =20
> > is also exhibited in the resulting File.getURL() method used by the
current=20
> classloader =20
> > mechanism in Cocoon. getURL does produce an absolute path, but
doesn't resolve "../" =20
> > path components. =20
> >  =20
> > 2. There appears to be no code in the current classloader to prevent
multiple duplicate =20
> > URLs being added o a single URLClassLoader instance.  I discovered
this when I printed=20
> out =20
> > the result of a getURLs() method call and found three identical
classpaths.  This may not =20
> > cause any faults, but it certainly doesn't look like an efficient
mechanism in the =20
> > long-run. =20
> >  =20
> >  =20
> > If point 1 is fixed on 1.3 this might be related to the faults only
some people are =20
> > experiencing with the current classloader. =20
> >  =20
> >  =20
> > Stuart. =20
> >  =20
> >
------------------------------------------------------------------------
- =20
> > Stuart Roebuck
stuart.roebuck@adolos.com =20
> > Lead Developer                                  Mac OS X, Java, XML,
etc. =20
> > ADOLOS
http://www.adolos.com/ =20
> >  =20
> =20
> =20
>
------------------------------------------------------------------------
-=20
> Stuart Roebuck
stuart.roebuck@adolos.com=20
> Lead Developer                                  Mac OS X, Java, XML,
etc.=20
> ADOLOS
http://www.adolos.com/=20
> =20


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