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 15:55:48 GMT
Le 22/01/15 15:45, Radovan Semancik a écrit :
> Hi,
> I'm working on rewrite of ConnId LDAP connector by using Apache LDAP
> API. This connector is used by our own midPoint project but also by
> Apache Syncope. The goal is to have clean Apache-licensed code as
> opposed to current convoluted CDDL-licensed and JNDI-based code.
> However I found this nice "// TODO Handle schema loading on other LDAP
> servers" in DefaultSchemaLoader. This is showstopper for me. The
> connector has to support a variety of LDAP servers otherwise there is
> no reason to develop it in the first place.

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.

Keep in mind that, if you except ApacheDS and OpenLDAP, no other server
will expose their schema in a standard way.
> So, I thought about implementing that part and contributing the code.
> But ...
> 1) I see that the code is maintained in Subversion. This is major pain
> point for me. Sending patches around is not really an efficient way to
> contribute. Is there another way that you would accept? E.g. pull
> requests over git?

We have git mirror (read only). Have a look at the end of

There is also a github repo :

(note that for historic reason, teh LDAP API is named Shared)
> 2) I have seen that the topic of schema support was discussed before.
> I guess that Emmanuel mentioned that there is a code to parse OpenLDAP
> schemas in the studio and that it can be moved into an utility class.
> Is there anyone willing to help with this refactoring? I would to it
> myself, but as I'm relatively new here I would probably make a lot of
> mess ...
> Especially the OpenLDAP schema support is quite important for me.
We do support OpenLDAP schema format. In fact, ApacheDS uses OpenLDAP
schema format, except for LDIF files. See later.
> 3) I haven't found any coding guidelines or practices for the project.

It's on We have
formatters for Eclipse in

> I've managed to build the sources from the "trunk-with-dependencies",
> but I'm not even sure if this is the right way to build it ... 

For the API, the easiest is to go into shared, and build everything with
mvn clean install. This is as simple as that.

If you don't want to run tests, then mvn clean install -DskipTests will

> is there anything that I should read to be able to contribute? 

Not so much. We have moved teh API recently to be fully OSGi compliant,
and that put a bit of constraints on the code (especially if you add
some new packages, but this is manageable).

All in all, regarding what you want to do, I think I need to give you a
bit of direction. See at the end of this mail.

> Or some recommendations?
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 );

That should work pristine with OpenLDAP.

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.

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.

Thanks !


View raw message