Le 22/01/15 18:03, Radovan Semancik a écrit : > >> 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?
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 > http://directory.apache.org/api/user-guide/4-schema-management.html 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. +1 > >> 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.
