[ApacheDS] Configuration in DIT (CiDIT)

[Alex Karasulu <ak...@apache.org>]

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

Re: [ApacheDS] Configuration in DIT (CiDIT)

[Alex Karasulu <ak...@apache.org>]

On 7/11/07, David Jencks <da...@yahoo.com> wrote:
>
> I would hope at some point these could be generated from
> the functional objects through something like xbean-spring + jaxb or
> ole's approach.


Hmmm not sure what you're suggesting here.  You mean like having annotations
in
the component (a.k.a. functional object) that are used to define the
configuration data?

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.


This is to make it easier to map config data into  LDAP data types without
having
funky rules on how it is interpreted.  Data in LDAP entries directly
translate into
properties in configuration beans without some kind of extra interpretation
which
may require instantiating functional objects.  The Spring configuration has
many
extra implicit meanings in how it builds beans: it's not just about simple
configuration
data alone.

I'm still worried by the configuration in ldap idea..... I sure hope
> its comprehensible without living in eclipse.


It's really not that big of a deal since LDAP can be used from the command
line as
well.  Also having the configuration in the DIT will make using JMX to
access and
manage the configuration easier as well.

The XML stuff can still be used to override the smart defaults the server
would use
in the DIT also.  So you just get the best of all worlds.

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
> >
> >
>
>

Re: [ApacheDS] Configuration in DIT (CiDIT)

[David Jencks <da...@yahoo.com>]

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
>
>