directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [ApacheDS] Configuration in DIT (CiDIT)
Date Thu, 12 Jul 2007 03:06:09 GMT
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
>
>


Mime
View raw message