Shibboleth Developers

[Tom Scavo <>]

I've filed a bugzilla for this issue:

http://bugzilla.internet2.edu/show_bug.cgi?id=423

See below for responses.

On 8/22/05, Chad La Joie 
<>
 wrote:
> Tom Scavo wrote:
> 
> >>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.

You didn't respond to this, Chad, so I assume you agree it's a bug.

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

Seems reasonable to me.  X509SubjectNameNameIdentifierMapping is a good 
example.

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

Ignoring the possibility of multiple extensions for the moment, a
simple reordering of the classpath elements fixes this.

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

Yes, order is important (that's the point of this thread :) but the
problem of search order in custom/lib exists apart from the
Shibboleth->Extension vs. Extension->Shibboleth ordering dilemma.

> I'm not saying your wrong for wanting what you do, I just wasn't
> thinking about this process in that manner.

Well, it's something to discuss, I guess.  More importantly, class
directories need to be searched before lib directories, right?  This
needs to be fixed in the buildfiles, I think.

Thanks,
Tom