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