geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <>
Subject [jira] Closed: (GERONIMO-420) Refactor *UserPrincipal and *GroupPrincipal
Date Tue, 16 Nov 2004 23:13:24 GMT
     [ ]
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:
>      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
> 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:
If you want more information on JIRA, or have a bug to report see:

View raw message