Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> > 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?

Hmm...  I'm actually not sure.  It used to be that Java loaded classes 
files as a single unit.  So it didn't matter if the signatures were the 
same or not, it just loaded the first class with a given name that it 
came to.  That said, now that I think about it, I suspect 1.5 might have 
different behavior because it doesn't necessarily load class files as a 
unit.

> > 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?

Well, in my mind at least, the extension mechanism wasn't supposed to 
allow you to override any arbitrary class, in fact I wasn't thinking it 
would allow you to override ANY class.  Instead it was a way to build, 
package, and deploy, inside the normal IdP/SP build process, code that 
plugged in to pre-defined extension points.  Those points being defined 
by the various configuration files.

Now, if the rest of the Shib team wants to take your view on it, that's 
fine, but it will require a bit of rework.  For example, most containers 
load jars, within a webapps lib directory, in lexicographical name 
order, so we'd need make sure that the WAR used the classpath ordering 
mechanism allowed in the archive manifest file to set an explicit order. 
 There are, I would guess, other issues to, but that was the one that I 
thought of first.

I'm not saying your wrong for wanting what you do, I just wasn't 
thinking about this process in that manner.
--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124