directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject [Schema refactoring] Partitions refactoring
Date Thu, 03 Sep 2009 06:45:11 GMT
Hi guys,

we are moving to the next step of our refactoring, now that both the 
registries and the LDIF loader have been refactored. First, let's 
summarize what has been done so far :
- We now have a working Registries set, which contains registries for 
every SchemaObject, and it works pretty well. A checker has been added, 
which control that all the elements are playing fine all together.
- The LDIF representation of the schema has been created, and a loader 
has been written. The Registries container is now correctly loaded from 
this LDIF representation (either from the file system or from a Jar)
- Many of the ADS subprojects are now passing unit tests, and we don't 
have any more compilation issue in the whole server ! Here is the list 
of building sub-projects :

OK    [INFO]   Apache Directory Project
OK    [INFO]   Apache Directory Shared
OK    [INFO]   Apache Directory Shared ASN.1
OK    [INFO]   Apache Directory Shared Ldap Constants
OK    [INFO]   Apache Directory Shared Ldap
OK    [INFO]   Apache Directory Shared JNDI
OK    [INFO]   Apache Directory Shared LDAP Schema
OK    [INFO]   Apache Directory Shared LDAP Schema Loader
OK    [INFO]   Apache Directory Shared ASN.1 Codec
OK    [INFO]   Apache Directory Shared Ldap Converters
OK    [INFO]   Apache Directory Shared Cursor
OK    [INFO]   Apache Directory Shared LDAP Client API
OK    [INFO]   Apache Directory Shared DSML Parser
OK    [INFO]   Apache Directory Daemon
OK    [INFO]   Apache Directory Daemon Bootstrappers
OK    [INFO]   Apache Directory Daemon Plugin (Maven 2)
OK    [INFO]   ApacheDS
OK    [INFO]   ApacheDS JDBM implementation
OK    [INFO]   ApacheDS Core Entry
OK    [INFO]   ApacheDS XDBM Base
OK    [INFO]   ApacheDS Core Constants
OK    [INFO]   ApacheDS Core AVL
OK    [INFO]   ApacheDS Generalized (X) DBM Tools
OK    [INFO]   ApacheDS JDBM Store
OK    [INFO]   ApacheDS Generalized (X) DBM Search Engine
OK    [INFO]   ApacheDS Core Shared
OK    [INFO]   ApacheDS Utils
OK    [INFO]   ApacheDS Core
OK    [INFO]   ApacheDS Core JNDI
OK    [INFO]   ApacheDS Protocol Shared
OK    [INFO]   ApacheDS Protocol Kerberos Shared
OK    [INFO]   ApacheDS Protocol Ldap
OK    [INFO]   ApacheDS Server JNDI
OK    [INFO]   ApacheDS Interceptors for Kerberos
OK    [INFO]   ApacheDS All
Failing    [INFO]   ApacheDS JDBM Partition
Failing    [INFO]   ApacheDS Core Unit
Failing    [INFO]   ApacheDS Core Integration
N/A    [INFO]   ApacheDS Server Unit
OK    [INFO]   ApacheDS Protocol Ntp
[INFO]   ApacheDS Protocol Kerberos
OK    [INFO]   ApacheDS Protocol Dhcp
OK    [INFO]   ApacheDS Protocol Dns
OK    [INFO]   ApacheDS Protocol Change Password
N/A    [INFO]   ApacheDS Server Integration
N/A    [INFO]   ApacheDS jetty http server integration
N/A    [INFO]   ApacheDS Xbean Spring
N/A    [INFO]   ApacheDS Server XML File
N/A    [INFO]   ApacheDS Server Tools
N/A    [INFO]   ApacheDS Server Replication Service
N/A    [INFO]   LDAP API unit test
N/A    [INFO]   ApacheDS 1.5 Build With Dependencies

Now, we are working on refactoring the Partitions. Here is a status on 
what should be done.

- First, we now have a SchemaPartition Partition. It will be in charge 
of loading and updating not only the backend (ie, the remanent data), 
but also the Registries
- We are defining a In Memory partition, based on AVL trees
- We also are defining a LDIF partition

So we now have 4 kind of partitions : JDBM, In Memory, LDIF and Oracle 
(still to be added)

About the Partition implementations, as the SchemaPartition is a it 
specific, here is the current proposal :
- Partitions are described in the Spring configuration as we currently 
do : <JdbmPartition id="example'...> or <ldifPartition id="example"...> 
etc. The tag represent the kind of Partition backend we will use. The 
rational behind this choice is that each kind of partition has its own 
configuration (cache, index, working directory, etc)
- The SchemaPartition, as it has to update the backend *and* the 
registries, is different : it embeds its own backend partition :
<schemaPartition id="schema" ...>
  <ldifPartition id="schema" ...>
  </ldifPartition>
</schemaPartition>
If wanted, we can switch the backend by simply refering to the 
JdbmPartition, or whatever we want.

There is a bit more to do : the initialization process has to be 
reviewed and clarified, but basically, we initialize first the 
SchemaPartition, the the configurationPartition (when it will be added), 
then any other partitions in the order they are described in the 
configuration.

One other point : the list of loaded schemas is given as a configuration 
parameter in the SchemaPartition. it allows an admin to define which 
partition should be loaded, which one should be enabled or disabled.

There are lot of work to do, but nothing we can't grok in a few days, as 
all the codeea already exists, it's just a matter of reassemble the pieces.

So now, let's code !

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message