[ http://nagoya.apache.org/jira/browse/GERONIMO-420?page=history ]
Aaron Mulder closed GERONIMO-420:
---------------------------------
Resolution: Won't Fix
It turns out it's useful to be able to distinguish. Might want to move common
code into a superclass, but don't want to replace subclasses.
> Refactor *UserPrincipal and *GroupPrincipal
> -------------------------------------------
>
> Key: GERONIMO-420
> URL: http://nagoya.apache.org/jira/browse/GERONIMO-420
> Project: Apache Geronimo
> Type: Improvement
> Components: security
> Versions: 1.0-M2
> Reporter: Aaron Mulder
>
> It would be nice if the default security realms all used the same user and
> group principal implementation classes. For one thing, the code is 99%
> identical across all 4 existing implementation classes. But also, these are
> essentially generic, and it would be nice to provide generic implementations
> of users and groups that custom login modules could take advantage of,
> instead of setting the precedent that every module must have a new and
> different set of principal classes.
> If we truly make the user and group principals generic, we would lose the
> current behavior that equals() can distinguish between a SQLUserPrincipal
> "foo" and a PropertiesFileUserPrincipal "foo", but I'm not sure that's all
> that important anyway -- the required class name goes into the configuration
> files, so if the class name isn't correct then the principal needs to be
> discarded regardless of what equals() reports. Plus, a principal "foo" from
> FileRealm "bar" is not actually the same as a principal "foo" from FileRealm
> "baz" even though the user principal implementation classes and user
> principal names are both the same -- so the current equals implementation
> isn't fully correct anyway.
> However, if we still want different classes for different realm types for any
> reason, we could at least put all the code in a base class and then have
> empty subclasses.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
