You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jeremy Grodberg <as...@nuru.net> on 2005/02/11 02:41:01 UTC

JAASRealm and useContextClassloader="true"

Is anyone using the JAASRealm with the useContextClassloader flag set 
to "true" in Tomcat 5.0.28?  It is not working the way I expect it to.

Although the posted documentation is confusing, reading the history 
of the flag in Bugzilla (see 
http://issues.apache.org/bugzilla/show_bug.cgi?id=29406 )leads me to 
expect that if I set the flag to "false" then the LoginModule, User, 
and Role classes (and their supporting classes) would all be loaded 
by the webapps's class loader.  That is to say they could all come 
from webapps/MyWebApp/lib and should be unaffected by any classes 
server/lib.

I've tried this configuration and it works as I expect.  I can stuff 
whatever JARs I want in server/lib and it doesn't break anything.


When I set the useContextClassloader flag to "true" on the other hand 
(or leave it out, since "true" is the default setting), I expect the 
LoginModule, User, and Role classes (and their supporting classes) 
would all be loaded by the Tomcat Server/Container's class loader. 
That is to say they could all come from server/lib (or common/lib) 
and should be unaffected by any classes in webapps/MyWebApp/lib.

I've tried this configuration and this only partly works.  With 
useContextClassloader="true" I can put all the classes in server/lib, 
yes, and they will work, yes, UNLESS the webapp being protected has 
the same classes in its library.  When the webapp being protected has 
the same support classes as the LoginModule, then I get NoClassDef 
errors as some LoginModule support classes get loaded by the 
Server/Container class loader but somehow the LoginModule starts 
looking for other support classes using the WebApp classloader.

In other words, I can break a working JAASRealm implementation 
(installed in server/lib and configured with 
useContextClassloader="true") by installing a new webapp that uses 
it.  To keep the JAASRealm working I have to remove stuff from the 
webapp, remove stuff from server/lib, and put it in common lib.  That 
defeats the whole idea of packaged webapps that are simply installed 
and work in their own little world.

It seems obvious to me that this is a Tomcat bug: the point of the 
separate classloaders is to prevent exactly this outcome and keep the 
Server unaffected by any webapp's libraries or other junk and to keep 
the webapps from being broken by stuff the Server needs.  The Tomcat 
developers, however, seem to think this is not a bug, but rather the 
expected behavior.

Would anyone be willing to help me understand why this behavior is 
expected and/or desirable?  Can anyone explain what would be wrong 
with having useContextClassloader="true" work the way I expect it to? 
I certainly would like to be able to have one LoginModule work for 
all the installed apps without worrying what libraries the webapps 
are using.

Thanks,
=Jeremy=

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org