Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> On 8/22/05, Chad La Joie 
> <>
>  wrote:
>
> > I don't understand how that's a problem.
>
>
> I explained it already a couple of times. :-)  First of all, it goes
> against the grain since that is not the way the container resolves
> class files.  

Correct, but neither is your way.  Different containers load classes 
differently.  For example, Tomcat starts with the JVM classpath to boot, 
then supplements that with a boot classpath.  It then creates a new 
class loader for the Catalina server process which loads stuff from the 
server's lib directories in a staged manner.  Then, for each web 
application it creates an additional class loader and loads the classes 
and jars (in lexicographical order).  JBoss, on the other hand, creates 
ONE classloader for the webapp container, which they refer to as a 
unified classloader, and loads everything in to that unless you tell it 
otherwise.

Once the class loaders are established class resolution is also 
dependent on the containers.  Most containers support a descendant first 
class loading model, which means classes are first looked for within the 
lowest classloader (usually the one created for the war, but even that 
one may have descendants) and then it moves up the chain looking for 
classes.  Some containers, and a standard JVM do the opposite, starting 
with the first, system level, classloader and work their way down to the 
lowest one looking for classes.

The best you can hope for is the ability to control the order in which 
the WAR's classloader will load the JARs within the WAR, but this says 
nothing about the effective classpath and the mechanism by which you 
might order the loading of resources within the WAR are optional and 
need not be honored by the container.  Nor can you control whether it 
loads the JARs before the classes or vice versa (this differs between 
containers too).

More importantly, it causes a unit test to fail since
> the VM finds an old class file in the JAR before it finds a new class
> file in the class directory.  A workaround is to run the unit test
> twice (with no mods in between) but that gets old rather quickly. :-)

In what JAR?  The resulting jar containing the extension code is not on 
the classpath of the extension during unit test execution.  The lib 
directory that IS on the classpath is, as I said, for libraries that the 
extension needs and would be stuff like Xerces, Commons libs, etc.

So, are you seeing an error where your unit test isn't picking up the 
latest changed to your code?
--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124