directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [ApacheDS] Merged schema branch into trunk
Date Sun, 31 Dec 2006 20:05:58 GMT
Hi all,

First off Happy New Year to everyone!

I just committed the merge of all the work I've been doing for the past 
couple weeks in the schema branch into the trunk.  There are some major 
changes to the structure of the project and to the internals of ApacheDS 
so I figured I'd give an outline of the changes here:

First there are a few new sub modules for ApacheDS:

   => contains schema partition db files
   => generates schema partition db files
   => btree partition specific shared interfaces and classes
   => constants used and shared throughout the server
   => minimal jdbm based attributes store with no deps on core
   => schemas needed for bootstrapping
     (core,system,apache, and apachemeta ONLY)
   => additional schemas - all other schemas
   => registry interfaces and implementation classes
   => some utilities

Lots of package and module breakups were performed to prevent cyclic 
maven module dependencies from emerging.  The core is tightly wound up 
so this took some work.  Over all the organization has improved a little 
bit.  Some cleanups are still needed.

So what's new?  Well now ApacheDS uses a special schema partition to 
store all schema information within a partition using the meta schema. 
This new partition is preloaded and packaged into a jar for extraction 
with all the schema known to ApacheDS and can be extended.

ApacheDS has now changed it's startup sequence to use this new 
partition.  Here's what happens:

(1) a set of minimal schemas are loaded into temporary schema registries

core, apache, system and apachemeta schemas

(2) this "bootstrapping" set of schema are used to initialize the schema 

(3) the schema partition is then used to load the global schema

(4) bootstrap temp registry is replaced by global schema

(5) server comes up as it did before using the global schema

This is a big step forward in our plan to enable dynamic schema.  It is 
the first major step.  Schema is not yet dynamic.  Several major changes 
are required to reach our goals.  Here's what roughly needs to be done:

(1) write interceptor code to modify registries on changes to schema entries
(2) write virtualized subentry lookup code
(3) write code to detect and configure all SAAs on startup or during 
runtime when new SAAs are created on the fly
(4) devise a way to store subsets of global schema for SAA registries
(5) use these partial registries to control schemas in SAA

So there is lots to still do.  However with this first *BIG* step we're 
much closer to the finish line.

Happy New Year,

View raw message