directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [ApacheDS] Bootstrapping phases well defined
Date Thu, 03 Sep 2009 23:36:53 GMT
On Fri, Sep 4, 2009 at 2:19 AM, Emmanuel Lecharny <>wrote:

> Alex Karasulu wrote:
>> <please-leave-this-link-on-responses>
>> </please-leave-this-link-on-responses>
>> Hi all,
>> To clarify the bootstrapping process that we're envisoning for ApacheDS,
>> I've written up the following page in the wiki [0].  Use the link above
>> instead since it's not going to hit confluence and shows the fast exported
>> page.  Take a look an provide your feedback here.  We can later adapt this
>> page to include your comments and recommendations.  So let's kick this off
>> with some thoughts?
> A few thoughts :
> 1) why do we need to have /schema/schema/... hierarchy, instead of having
> one single /schema  ?

Good question.  This repository of schema information encoded in LDIF models
the layout of the schema partition's DIT namespace.  The ou=schema context
is the second 'schema' directory which has a schema.ldif file right next to
it.  The reason we have to put the LDIF file next the directory is due to
the fact that the directory contains the children but requires an LDIF file
to contain the attributes for the node.  Together the LDIF file and the
folder represent entries with children.  In some places you won't see a
directory like for example in a schema that does not have any nameForms (no
schema at this point does).  So all you see is the nameForms.ldif for the
nameForms container but since there are no children to contain the directory
is not present.

The first topmost schema folder is simply the partition container if the
partition is the LDIF partition.  The schema partition's id = schema like
the system partition's id = system.  And as you probably know, ApacheDS uses
the ID of the partition to create and name the directory where the partition
resides on disk, whatever the format of it's storage.  So when you unpack
this jar into the partitions directory of the instance, it unravels it in a
top most schema directory that will contain this schema.ldif file and the
schema directory.

> 2) I don't get the chicken and egg problem you describe and why we need a
> special wrapped partition
> to read the four initial schema : they are just read and injected into the
> registries, without
> any check, that's pretty much it. I do'nt see how it's different from any
> other schema loading,
> to me all the schemas are loaded in one unique phase. probably some
> semantic sugar at this point ...
No semantic sugar, not sure I understand what this means either so maybe I
cannot say no either at this point.  But let me explain what I can about the
chicken and egg problem.  We need schema to enable a partition containing
schema.  This is the crux of the problem.

We get around this problem by loading the 4 bootstrap schema from the jar
file rather than the schema partition which contains all the schema.  We use
two different loaders in the different schema loading phases.  The first
bootstrap phase uses a JarLdifSchemaLoader and the second full schema load
phase uses the PartitionSchemaLoader.  So there is a distinct difference in
how we load although to the Registries getting loaded this feels the same.

> 3) Not sure I get the point about the LDAP Nirvana yet. The wiring part is
> a bit obscure.
> Some schema can help, I will try to add them tomorrow.
>  OK if you ask more specific questions I can probably answer but I'm a bit
spent right now to try to revamp this section.  You're probably right about
it being obscure.  Might take a look at it again and see if I can fill it in
with more details.

> Thanks for the page !

>  ---
>> [0] --
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::

View raw message