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
<property name="name" value="normalizationService" />
<property name="name" value="authenticationService" />
<bean class="org.apache.directory.server.core.authn.AuthenticationService" />
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.