directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Client API Schema support
Date Thu, 22 Jan 2015 17:27:20 GMT
Le 22/01/15 18:03, Radovan Semancik a écrit :
>> We have git mirror (read only). Have a look at the end of
>> There is also a github repo :
> Yes. I have seen that. But the question is: will you accept a
> contribution in a form of pull request on github?

I think so. We need to try !
> Ok, now some explaination on how the whole Schema system works.
>> First of all, you have to understand that the API can work with our
>> without schema. The schema is really an optional piece. Now, when you
>> want to use a schema, all the methods will be passed an instance of what
>> we call an SchemaManager. So the very first thing you have to do is to
>> have an instance of a SchemaManager. How do you get such a beast ?
>> The response will depend on where you pull the schema from. We use
>> SchemaLoader instance for that purpose, and we have various flavors :
>> - LdifSchemaLoader : loads all the schema elements from the disk,
>> assuming they are stored as LDIF
>> - SingleLdifSchemaLoader : same thing, but the schema elements are
>> stored in one single fiule instead of many
>> - JarLdifSchemaLoader : same thing, except that we are reading the
>> schema elements from a Jar file
>> - DefaultSchemaLoader : loads a schema directly from a server
>> The last one is most certainly what you are interested in. What it does
>> is that it reads all the stored schema elements description, in a format
>> that is described in RFC 4512. We pump the AT, OC, etc from the
>> subschema subentry. Usually, it's stored into the rootDSE.
>> Once we have those elements, we parse them into something we can play
>> with, and when it's done, we check that the schema is consistent. If so,
>> you now have a valid SchemaManager that is going to be used all over the
>> API, silently - ie, you don't even have to tell the API to use it).
>> At the end of the day, it boils down to create a LdapNetworkConnection,
>> call loadSchema() on it, and you are all set :
>>                      connection = new LdapNetworkConnection(
>> configuration );
>>                      connection.loadSchema();
>> That should work pristine with OpenLDAP.
> Yes. I have already figured that out.
> BTW, it would be great to copy&paste this text at a proper place at

Exactly what I was telling myself : why the hell should I explain all
that again and again on the ML when it could be put on teh web site ...

> Especially the piece of code, together with
> schemaManager = connection.getSchemaManager();
> it took me a while to figure that out. Placing it in the guide will
> definitely help other developers.

>> Now, there are two other use cases :
>> - first, you don't want to connect to a LDAP server (because you have
>> many possible ones), and you want a shared schema between those guys.
>> Here, I whish you good luck, as the schema will varry a lot between
>> OpenLDAP, AD, etc... Although you can make it work, but you have to load
>> the schema from some local data (here, it will be a LDIF file, using
>> ApacheDS format, or a OpenLDAP format file). if it's from a OpenLDPA
>> formated file, you will need to convert it, which is done by the
>> SchemaParser file.
>> - second, you want to connect to a LDAP server which uses a different
>> format. You will have to write a parser for what you get...
>> My guess is that option 1 is the best for your need.
> It is option 2. I do want to connect to LDAP server and I want to
> download the schema and I want to process the schema dynamically. This
> is what a good IDM system does (such as midPoint :-)) ... and actualy
> all the code to process the schema is already in place is it work
> quite well with JNDI. Including the schema retrieval from the server.
> So I positively know that this is possible. I need to support only
> several schema styles (OpenLDAP, the Netscape family, OpenDS/OpenDJ
> and eDirectory). And there are all quite similar. Currently I do not
> really care about the rest. So this should be quite feasible.
> I do not really need the schema checking inside the API. MidPoint does
> that already. But having the checking is not a problem, it is just
> added benefit. 
The checking can be disabled.

> What I really need is to download the schema from LDAP server,
> represent it in the Apache LDAP API terms (ObjectClass, AttributeType
> and similar) . This is what I want to contribute to the API. Then my
> connector takes that and converts the schema to the ConnId
> terminology. This makes it a "universal" IDM schema which is not
> LDAP-specific. midPoint takes it from there ... and this is really a
> long story that is not important for this discussion.
> So it looks like all I need is to implement that "// TODO Handle
> schema loading on other LDAP servers" part, right? :-)

Most certainly. We use an antlr parser to do that with what we get from
OpenLDAP/ApacheDS, it should be easy to do the same thing for other servers.
>> What I would need at this point is an exact description of what you want
>> to do in order to drive you toward the various classes of teh API.
> Maybe if you can describe how to support OpenLDAP server there .... I
> think I can figure out the rest.

I'll do that after dinner.

View raw message