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
http://directory.apache.org/sources.html
There is also a github repo : https://github.com/apache/directory-shared
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 http://directory.apache.org/api/developer-guide.html. We have
formatters for Eclipse in
http://svn.apache.org/viewvc/directory/project/trunk/resources/
(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
http://directory.apache.org/api/user-guide/4-schema-management.html
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
evolveum.com
