Konstantin Kolinko wrote: > 2009/7/17 Mark Thomas <ma...@apache.org>: >> As a result of looking into >> https://issues.apache.org/bugzilla/show_bug.cgi?id=40881, I discovered >> that the only use made of the Realm attribute of GenericPrincipal is to >> control whether or not a debug message is logged in RealmBase.hasRole() > > Looking at > http://svn.apache.org/viewvc?view=rev&revision=301601 > > That revision comment says about switch to commons-logging, but > besides just that the > "if (!(gp.getRealm() == this))" block was changed from returning false > to just logging a message. > I am not sure, that it was intentional.
The commit message indicates that it was intentional. > Or there was really a bug with jaas, that this change fixed? I think it is safe to assume Costin wasn't making this up. > Is there a use case, besides replication, where a Principal is > processed in context of some other realm, some other realm instance, > different from the one that created it? Single Sign On uses a shared Principal >> Given that the Realm is the reason that GenericPrincipal is not >> Serializable, I'd like to propose the following changes for Tomcat 7. >> >> 1. Remove the Realm from GenericPrincipal >> 2. Make GenericPrincipal Serializable >> 3. Take advantage of this to simplify the Cluster code > > I think "3." includes removing the > o.a.c.cluster.session.SerializablePrincipal class Yep :) >> As a by product, this should also address bug 40881 by allowing any >> Realm that uses any Serializable Principal to work with clustering. >> > > I attached a patch to that issue, see comment #12: > https://issues.apache.org/bugzilla/show_bug.cgi?id=40881#c12 > It is to allow a serializable Principal to be written out and read in > during replication. > > Cannot test it, though, as I do not have relevant configuration now. I see where you are going with that. That could be a potential backport route for 6.0.x and 5.5.x but for 7.0.x I can't see a good reason to include the Realm in the Principal and several for getting rid of it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
