-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> 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 server. Does that clear things up a bit? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLdNwACgkQ9CaO5/Lv0PCKigCgo0atqiLoFv7lb8Pu9SRWM5hQ UIUAn0lRPmOpLtRkgy11Dgjii1dGH8wP =YrTu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
