Abstract group systems into GroupBackend interface.

Currently, every NameKey and UUID for a group is expected to be backed
by an entry in the AccountGroup table. In the future, the group
backend will be swapable by allowing implementations to scope
AccountGroup.UUIDs e.g. "ldap:<ldap identifier>". This change
adds a GroupBackend interface that abstracts the implementation details
of a group system with respect to looking up groups (editing and
creating are not supported), which should be used instead of GroupCache
when looking up by AccountGroup.UUID or name. GroupBackends scope which
AccountGroup.UUIDs they handle by implementing the handles() method for
a particular prefix. The UniversalGroupBackend is a GroupBackend that
delegates methods to the GroupBackend that handles() the UUID, using
DynamicSets. The InternalGroupBackend and LdapGroupBackend are
the first GroupBackend implementation. It should be possible to bind
many GroupBackends concurrently, unfortunately, the current
implementation of LdapGroupBackend.handles() overlaps with the
InternalGroupBackend.handles() (since they are both stored in the
database), so only one those implementations may be bound at once.

Change-Id: Ieda21916247084ebc2dffc9dd82d3e1230b9ab64
This commit is contained in:
Colby Ranger
2012-05-02 09:02:03 -07:00
parent 8363aa5144
commit 2ac82b021f
34 changed files with 965 additions and 234 deletions

View File

@@ -15,11 +15,8 @@
package com.google.gerrit.server.account;
import com.google.gerrit.reviewdb.client.Account;
import com.google.gerrit.reviewdb.client.AccountGroup;
import com.google.gerrit.reviewdb.server.ReviewDb;
import java.util.Set;
public interface Realm {
/** Can the end-user modify this field of their own account? */
public boolean allowsEdit(Account.FieldName field);
@@ -34,8 +31,6 @@ public interface Realm {
public void onCreateAccount(AuthRequest who, Account account);
public GroupMembership groups(AccountState who);
/**
* Locate an account whose local username is the given account name.
* <p>