directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <>
Subject Re: Client API Schema support
Date Thu, 22 Jan 2015 17:03:34 GMT
On 01/22/2015 04:55 PM, Emmanuel L├ęcharny wrote:
> This comment is just a reminder that, at some point, we want to be able
> to load schema from many different serters. It's not mandatory to do
> that though : you can either work with the API without any schema (and
> we will then be very limited with the controls we can do locally), or
> you can define a local schema that will be used when dialoging with a
> remote server.

None of that is an option for me. I need to have schema-aware connector 
and it needs to download the schema from the server.

> Keep in mind that, if you except ApacheDS and OpenLDAP, no other server
> will expose their schema in a standard way.

Yes. I'm aware that there may be lot of "magic" to implement there. :-)

> 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?

>> 3) I haven't found any coding guidelines or practices for the project.
> It's on We have
> formatters for Eclipse in
> (formatting.xml)

Thanks. That's exactly what I have been looking for.

> 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
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. 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? :-)

> 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.


                                            Radovan Semancik
                                           Software Architect

View raw message