If you really have configuration data objects then I agree that its
pretty essential to have only data in them and no actual functional
objects. I would hope at some point these could be generated from
the functional objects through something like xbean-spring + jaxb or
ole's approach. Something we discovered in geronimo is that most
people don't like to have to specify any metadata in their objects --
our attempt to ask people to tell us what their component looked like
(GBeanInfo) has met only resistance. I don't fully understand why
you need the configuration objects with spring, rather than having
spring create the functional objects directly.
I'm still worried by the configuration in ldap idea..... I sure hope
its comprehensible without living in eclipse.
thanks
david jencks
On Jul 11, 2007, at 9:48 PM, Alex Karasulu wrote:
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.MutableIntercept
orConfiguration">
<property name="name" value="normalizationService" />
<property name="interceptor">
<bean
class="org.apache.directory.server.core.normalization.NormalizationSer
vice " />
</property>
</bean>
<bean
class="org.apache.directory.server.core.configuration.MutableIntercept
orConfiguration">
<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
