shibboleth-dev - Re: class loading order
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To:
- Subject: Re: class loading order
- Date: Mon, 22 Aug 2005 09:39:39 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YGlseSPpQQ3mAy0yCwis3R+625mLPI411/T+HeqcxP2Kpf9G3CWqG5j6kLuaCZg8BJ7f1NfZj38Nl4nH8SbT0t7+4nOv6tYr09QNvTBPLScO3ei36qBKDSMOSgZ8eFzNGQKdPoVQanDMYLbSRbsMB3i+42x/pIiCLSh2IgXQMrI=
On 8/22/05, Chad La Joie
<>
wrote:
> I'm not sure why you start out by talking about the Tomcat class loading
> mechanism and then switch to the build stuff.
To emphasize the fact that unpacked class directories are typically
searched before JAR files.
> In ant, tasks that take paths using things like pathelement or classpath
> elements just compose a single class path BEFORE the parent operation
> runs. So, the ordering of items generally doesn't matter.
That is not the behavior I'm seeing, no. The order does appear to
matter (see below).
> Now, I said it generally doesn't matter which order elements appear in.
> When it does matter is when you have multiple classes with the same
> name but differing signatures, at which point the JVM just uses
> whichever it finds first.
Do you mean the same name with the *same* signature?
> Don't do this, it's bad (and the extension
> FAQ says not to do it). :)
Are you talking about README.txt? It warns against duplicate JARs,
which I assumed was referring to 3rd-party JAR files. That is not the
issue here.
> So, are you seeing an error, if so what is it?
As far as building the extension, no, I have seen no errors as a
result of the classpath. Unit testing is another matter, however.
The unit tests in ext.test.src are not even compiled, let alone
executed. I hacked extension-build.xml to do this, and discovered the
order of the classpath elements DOES matter. If you include the
extension JARs BEFORE the extension class files, there's a delayed
reaction before changes take effect, that is, you have to run ant
twice before it finds the updated unit test classes in the JAR.
Instead it should look in the build directory before searching the JAR
files.
Moreover, the classpath should search the extension classes and JARs
before the Shibboleth classes and JARs. Then I can override
X509SubjectNameNameIdentifierMapping without changing the name and
polluting the namespace. In general, an extension should be able to
override any Shibboleth class in this way. How else would you
distribute patches and such with this mechanism?
Tom
- class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
- Re: class loading order, Tom Scavo, 08/22/2005
- Re: class loading order, Chad La Joie, 08/22/2005
Archive powered by MHonArc 2.6.16.