Hi all,

I've been rearranging and cleaning up some of the modules and packages (minimally for now) in my LDIF branch.  There are multiple aims behind this action but one of them is to enable users to be able to specify any partition implementation to be used as the schema/system partition.  I can now see clearly how this can be done. This email describes how and the tradeoffs.

Change #1: Merge Schema & System Partitions

First we have to merge the system and schema partitions into one. There should only be one partition required to start the server.  The ou=schema area should be relocated to:


A single partition containing all critical startup information helps replace this partition with any implementation.  Later this will also help when implementing our configuration in DIT solution.

Change #2: Alter Initialization and Startup

I have modified (and renamed) the init method (now initialize()) on the Partition interface to only require schema Registries. This was done to allow Partitions to be initialized and made usable before the DirectoryService has been started or even created. Before, the Partition interface required a DirectoryService instance to initialize. There was no easy way we could provide a hot Partition to the DirectoryService to startup() itself if Partitions required a live DirectoryService.  Chicken and egg should come to mind.

Let's require the DirectoryService be provided a hot partition, specifically the system partition.  Initialization of the DirectoryService will be delayed until this Partition is made available to provide the configuration and schema data needed for bootstrapping the service.

Programmatic Configuration vs. DIT Configuration

Zoerner really stumped me with this one at ApacheCon and I did not have an immediate answer (must have been the beers). Just for the record I will repost it here:

    "When embedding with CiDIT, which configuration is the authoritative configuration: the programmatic configuration or the configuration in the DIT?"

Hope this is right Stefan.  Please correct me if I'm wrong.

We will take a simple common sense approach.  Any application embedding the DirectoryService will simply delegate configuration to it.  Meaning the configuration in the *system* Partition will drive the wiring and configuration process.  There will be no need to programmatically configure the DirectoryService.  So how can embedding applications alter the stock configuration that ships with ApacheDS?

(1) With dynamic reconfiguration the stock partition containing a basic configuration can be altered after the DS is started up by an embedding application and these changes will persist. 
(2) LDIFs can be loaded right after startup to alter the configuration which will dynamically alter the server.
(3) A custom 'system' partition with the preferred configuration can be supplied. 

Thoughts? Comments?

Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org