Hi Ole, Stefan,
I just wanted to add some more information to this. LDAP schema according to the standard can
be composed of the following kinds of entities which govern various aspects of the schema
In ApacheDS 1.5.0 and above we have some additional schema entities specific to ApacheDS which
were devised to facilitate the dynamic extension of the schema:
These atomic elements allow users to actually implement and load code into the server to create
new Syntaxes and MatchingRules. They are the building blocks for defining the behavior of Syntaxes
In traditional LDAP servers which lack these elements there was no way to dynamically add new
matchngRules or syntaxes without a restart if you could at all extend the server to do so. Basically
you were stuck with the syntaxes and matchingRules hard coded into these servers. The protocol
standards which define a grammar for specifying matchingRules and syntaxes are extremely simple.
They merely state that a matchingRule or syntax exists within the server with an OID for it. This is
not enough to specify the behavior for these constructs. For example a syntax spec might look like
( 18.104.22.168.4.1.1422.214.171.124.15 DESC 'Directory String' )
As you can see all a syntaxChecker does is announce the Syntax it validates and has two methodspublic interface SyntaxChecker
boolean isValidSyntax( Object value );
void assertSyntax( Object value ) throws NamingException;
It looks really good. I'll probably we frequenting that when I need
Also, I found Emmanuel's tip for browsing the Schema partition
(by adding an ou=schema connection) to LDAP studio really handy.
I'm not done reading yet, but I started with this:
The schema of an LDAP server is comprised of object classes, attributes,
syntaxes and matching rules. Basically it defines which entries are
allowed within the server and how the server should handle them. In
contrast to the 1.0 release, ApacheDS 1.5.0 comes with a completely
redesigned schema subsystem. It allows to dynamically update the schema,
for instance it is possible to create new attribute types or object
classes on the fly, i.e. without restarting the server.
Here's another attempt:
The schema of an LDAP server is a set of entries of the following types:
The first three types of entries are used to the schema rules /
structure of other stored in the server. ApacheDS 1.5.0 comes with a
completely redesigned schema subsystem. It enables dynamic schema
updates, like the creation of new AttributeType or ObjectClass entries
I still need to figure out MatchingRule entries...:-)
I think the only thing that needed grammatic fixing was this part:
It allows to dynamically update the schema,
The rest is just a suggestion.
Stefan Zoerner wrote:
> Hi all!
> I have started a little text for newbies on how to add custom elements
> to the schema with the help of the new schema subsystem of ApacheDS.
> First of all: I works fine to add elements with standard JNDI methods,
> well done, Alex!
> My first attempts for the text can be found here:
> I plan to make this an introduction section to the schema topic in the
> Advanced User's Guide of ApacheDS 1.5, although there is obviously still
> some work to do. Any feedback on the current structure and state of the
> section is therefore highly appreciated! I am a newbie on this schema
> subsystem as well.
> The section is build around an example of adding a custom attribute type
> (numberOfGuns) and a custom object class (ship) to the schema in order
> to add entries like this one for instance:
> dn: cn=HMS Victory,ou=ships,o=sevenSeas
> objectClass: top
> objectClass: ship
> cn: HMS Victory
> numberOfGuns: 104
> description: a ship of the line of the Royal Navy, built between 1759
> and 1765
> For adding numberOfGuns and ship to the schema I have to use OIDs, but I
> think it is not worth to register them officially below
> Should I use obvious fun data like 126.96.36.199.9.1 and 188.8.131.52.9.2, describe
> the idea of OIDs and that a user should normally obtain a unique
> starting point?
> Or should I use something which starts with 184.108.40.206.4.1.18060.0 and add
> it on the list. Perhaps we can add a branch for documentation examples.
> What do you think?
> Greetings from Hamburg,
> Stefan Zoerner (szoerner)