directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS] Configuration in DIT (CiDIT)
Date Thu, 12 Jul 2007 01:48:23 GMT
Hi all,

Here and there I started experimenting with moving the configuration into
the DIT.  The first
obstacle I encountered was the way in which our configuration really carries
functional objects
in it rather than configuration data which is primarily due to advantages in
using Spring for
configuration.  Let me elaborate more with a specific example.

Take the interceptors: these entities in the Spring configuration file,
server.xml, are listed as
beans which instantiate the actual interceptor classes themselves.  Let's
take a look into the
server.xml:

    <property name="interceptorConfigurations">
      <list>
        <bean class="
org.apache.directory.server.core.configuration.MutableInterceptorConfiguration
">
          <property name="name" value="normalizationService" />
          <property name="interceptor">
            <bean class="
org.apache.directory.server.core.normalization.NormalizationService" />
          </property>
        </bean>
        <bean class="
org.apache.directory.server.core.configuration.MutableInterceptorConfiguration
">
          <property name="name" value="authenticationService" />
          <property name="interceptor">
            <bean class="
org.apache.directory.server.core.authn.AuthenticationService" />
          </property>
        </bean>
  ...

As you can see the standard interceptor configuration object carries in it
the interceptor bean. The
interceptor's class is loaded and instantiated using the default constructor
and setter injected into
the interceptor property of the MutableInterceptorConfiguration object which
is also instantiated.

The problem here is that the configuration object contains the functional
components themselves.
This is not good if we just want to have purely configuration based beans.
What we want in the
interceptor configuration is the name of the service and the fully qualified
class name of the
interceptor to instantiate along with any custom properties associated with
the configuration.

As an experiment I modified the MutableInterceptorConfiguration bean class
to have two String
properties.  One for the name of the interceptor (really the id) and another
for the fully qualified
name of the interceptor class.  Then I modified the initialization sequence
to load this class
from the configuration rather than let Spring do it.  So if we are to do
this across the board we're
going to have to apply this pattern of operations:

    1. Modify all configuration beans to hold non-functional objects which
contain *only* config data
    2. Modify the initialization sequence for the respective components to
use configuration beans
        to drive instantiation and dependency injection for these
components.

Once all the configuration beans contain no functional objects (components)
themselves but just
the information needed to instantiate components and inject dependencies
then we are ready to
model configuration beans using an LDAP schema.  This is perhaps another
topic to consider
after getting the server.xml working with just these changes.

I'm going to go ahead and commit my changes to the trunk and begin working
on making partition
configurations use just configuration data instead of functional objects.  I
know we're close to a
release but I think I can get it done quickly.  Let me know if anyone has
any objections.

Thanks,
Alex

Mime
View raw message