| Alex Karasulu 2006-12-31, 7:11 pm |
| 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:
bootstrap-partition
=> contains schema partition db files
bootstrap-plugin
=> generates schema partition db files
btree-base
=> btree partition specific shared interfaces and classes
constants
=> constants used and shared throughout the server
jdbm-store
=> minimal jdbm based attributes store with no deps on core
schema-bootstrap
=> schemas needed for bootstrapping
(core,system,apache, and apachemeta ONLY)
schema-extras
=> additional schemas - all other schemas
schema-registries
=> registry interfaces and implementation classes
utils
=> 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
partition
(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,
Alex
|