Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> On 8/22/05, Tom Scavo 
> <>
>  wrote:
>
> > More importantly, class
> > directories need to be searched before lib directories, right?  This
> > needs to be fixed in the buildfiles, I think.
>
>
> This is the current path from extension-build.xml:
>
>     <path id="ext.path">
>         <!-- Shibboleth Libraries -->
>         <path refid="build.path" />
>
>         <!-- Shibboleth Classes -->
>         <pathelement location="${build}" />
>
>         <!-- Extension libraries -->
>         <fileset dir="${ext.lib}">
>             <include name="**/*.jar" />
>         </fileset>
>
>         <!-- Extension classes -->
>         <pathelement location="${ext.classes}" />
>         
>         <!-- Extension test classes -->
>         <pathelement location="${ext.test.classes}" />
>     </path>
>
> If order of path elments is important (and I think it is), this is
> wrong.  The path should be
>
>     <path id="ext.path">
>         <!-- Shibboleth Classes and Libraries -->
>         <path refid="build.path" />
>         
>         <!-- Extension test classes -->
>         <pathelement location="${ext.test.classes}" />
>
>         <!-- Extension classes -->
>         <pathelement location="${ext.classes}" />
>
>         <!-- Extension libraries -->
>         <fileset dir="${ext.lib}">
>             <include name="**/*.jar" />
>         </fileset>
>     </path>
>
> The explicit reference to ${build} is redundant and therefore not
> needed.  More importantly, extension classes need to be searched
> before extension JARs.

First, I took out the extra ${build} reference.  I hadn't noticed that 
that was included in the build.path.  Good catch.

However, Ant composes and uses the classpath as I suspected.  So, the 
first class found with a given name is loaded.  At this moment in time 
the use of extensions to override general classes within the Shib IdP/SP 
code is not supported and I'm not going to support that until I can talk 
it over with Walter and the rest of the Shib Dev team.

However, I can tell you at this point my vote is against this feature 
for two reason.  First, it's questionable whether this is supportable in 
a deployed environment.  It will require a standardized way of making 
sure that jars within the IdP/SP war are loaded in a particular manner 
in all containers.  Second, I think this could lead to some support 
problems.  If an extension supersedes a class from the standard Shib 
code and that extension code exhibits problems it will be difficult, if 
not impossible, to tell that it's not the standard Shib code causing the 
issues.  Along the same lines, if more than one extension tries to 
override the same class there will likely be major problems.

> Also, since the path needs to be modified anyway, I'll include the
> following nit.  The above path does triple duty since it's used for
> both compile operations and the unit testing,  but not all path
> elements are needed for all three operations.  Doesn't matter too
> much, I guess, but the multiple paths defined in build.xml are perhaps
> a better way of handling it.

Yeah, I went ahead and did this.  It doesn't make a difference 
functionally but after thinking about it again I think it's cleaner to 
look at and understand.

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124