tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <...@teamware.com>
Subject Re: JAAS/Classloaders/Tomcat4
Date Wed, 24 Oct 2001 07:22:15 GMT
Hi Craig,

Thanks for the reply.

"Craig R. McClanahan" wrote:
> 
> You should *not* be doing both of these things -- either put it on
> the classpath *or* put it in $CATALINA_HOME/lib.

I agree, but that's part of the problem, where do you put the jar file
if it needs to be on the system classpath, e.g. we use log4j in our
login module so this has to be on the system classpath too.  Should this
be put in bin like bootstrap.jar.  It's a bit overkill to put it in
$JAVA_HOME/jre/lib/ext.

> Have you tried putting JAAS in the System Extensions directory
> instead ($JAVA_HOME/jre/lib/ext)?  This directory is automatically
> added "above" the system class path.

Yes, that also works for jaas but the login module classes do not go
there.

> > There is no concept in Tomcat 4.0 of a system classes directory
> > where you can just dump the odd class as the classes directory
> > is used by the shared classloader.
> >
> 
> In Tomcat 4.0, the directory "$CATALINA_HOME/classes" is added to
> the shared classloader if it exists at startup time.  This would
> contain unJARed classes and resources, analogous to /WEB-INF/classes
> within a webapp.

The problem is the 'shared' classloader is no use for JAAS.  All user
login modules have to be on the system classpath and there is no dynamic
way to change Tomcat environment to add login modules without editing
the startup script.

> Tomcat 3.2 used the technique of actually modifying the system class
> path.
> Unfortunately, it causes platform specific problems, especially on 
> Windows where there are limits on the overall length of an
> environment variable, and lots of strange restrictions on building
> an environment variable dynamically in the script.  In addition,
> editing the class path manually has historically been the source
> of a very high percentage of newbie user errors.  The current
> approach that Tomcat takes (build class loaders internally based
> on the contents of directories) is much more reliable and less error
> prone.

I agree, the tomcat 4 way is a much better way, we have similar problems
of command line length with NT and dynamic classpath building and are
looking to adopt some alternative mechanism.

Rgds
Antony

Mime
View raw message