Juan Hernandez has posted comments on this change.
Change subject: [WIP] Introduce new directory interface
......................................................................
Patch Set 1: (3 inline comments)
....................................................
File
backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/directory/DirectoryManager.java
Line 55: /**
Line 56: * Loads the directory implementations that are available in the
class path
Line 57: * using the service loader mechanism.
Line 58: */
Line 59: private void loadImplementations() {
As I said the fact that a provider is available in the classpath and loaded
doesn't mean that is providing any directory. The administrator can
enable/disable directories at will using configuration, if the provider
supports so (the LDAP provider will).
Line 60: ServiceLoader<DirectorySpi> loader =
Line 61: ServiceLoader.load(DirectorySpi.class);
Line 62: for (DirectorySpi implementation : loader) {
Line 63: implementations.add(implementation);
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/users/Directory.java
Line 50: * with no particular order, note that the returned set may
contain less
Line 51: * elements than the given set of identifiers and that it may be
in a
Line 52: * different order
Line 53: */
Line 54: Set<DirectoryUser> findUsersById(Set<Guid> ids);
What I am asking providers is to keep the details of their implementation in
their implementation. We don't need to store the identifiers of an external
system in the engine database, and certainly not as expensive strings.
Line 55:
Line 56: /**
Line 57: * Retrieves a group from the directory given its identifier. Note
that this
Line 58: * identifier is the one assigned by the engine to the group, not
the one
Line 80: *
Line 81: * @param query the query
Line 82: * @return a list containing the groups that match the given query
Line 83: */
Line 84: Set<DirectoryGroup> findGroupsByQuery(String query);
So now it is ok to design these interfaces for LDAP? We already have that.
We already have a parser that generates an intermediate representation of the
query (see the SyntaxChecker class) and the query language supports things that
the LDAP filter language doesn't, like paging and sorting (those have to be
controls, not part of the query). So we don't need N parsers, only N
SyntaxCheckers, similar to the ADSyntaxChecker that we already have for LDAP.
--
To view, visit http://gerrit.ovirt.org/15596
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If84a0c9d6553d81cdbbe224972696f169cca90d4
Gerrit-PatchSet: 1
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Juan Hernandez <juan.hernan...@redhat.com>
Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com>
Gerrit-Reviewer: Juan Hernandez <juan.hernan...@redhat.com>
Gerrit-Reviewer: Oved Ourfali <oourf...@redhat.com>
Gerrit-Reviewer: Yair Zaslavsky <yzasl...@redhat.com>
Gerrit-Reviewer: oVirt Jenkins CI Server
_______________________________________________
Engine-patches mailing list
Engine-patches@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-patches
