tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: RealmBase's 'Container' requirement (revisited)
Date Thu, 05 Feb 2009 23:23:08 GMT
Hash: SHA1


Caldarale, Charles R wrote:
>> From: Christopher Schultz []
>> Subject: RealmBase's 'Container' requirement (revisited)
>> Should I continue down this road of trying to prop-up a
>> Tomcat skeleton server inside the webapp's space
> I'm confused (seems to be happening a lot lately): Tomcat already
> supports context-specific <Realm> usage, so what is the real capability
> you're providing? Would JMX allow you to create (and destroy) a
> context-specific Realm on the fly?

I'm trying to allow users of securityfilter to use Tomcat's pre-built
Realm implementations. securityfilter borrows the "realm" concept from
Tomcat but provides (IMO) much improved flexibility (outside the servlet
spec, of course) to form authentication. You can think of securityfilter
as a replacement for the container-based authentication and
authorization framework, without the Realm implementations. The
nomenclature is unfortunate, since Tomcat's Realms (and therefore
securityfilter's) are really authenticators... or maybe credential
validators if you prefer.

Basically, we have a CatalinaRealmAdapter class that wraps a Tomcat
Realm object and plugs it into securityfilter. Since all this work is
done within the webapp (and not in the container), catalina.jar and
friends need to be in the webapp's lib directory. This means that the
Tomcat internal classes (in the webapp) are separate from those loaded
by the system/server ClassLoader, so many things are null or not
available. As I mentioned, this used to work before the Realm objects
became more dependent on lots of infrastructure objects in the running

Does that clear things up a bit?

- -chris

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message