directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: [SASL] SASL configuration
Date Fri, 16 Mar 2007 01:37:36 GMT
Enrique Rodriguez wrote:
> On 3/15/07, Emmanuel Lecharny <> wrote:
>> ...
>> Sorry that we have to live with what we have for a little while... 
>> But it
>> also prove that we have reached a critical size  : it starts to become
>> complicated to change things :)
> Sounds good.  Our old OSGi build used config in the DIT and the OSGi
> Config Admin service to dynamically "inject" that config into a
> service, such as Kerberos, when it came online.
Racked what little grey matter I have over the problem of ADS config 
when I was doing the last OSGi impl.  Since this topic has come up in 
this thread allow me to share some details on the OSGi & SOA way to 
Configuration that Enrique was talking about.

The old OSGi impl used a hard coded configuration to bootstrap the DIT 
which once started registered an InitialContextFactory Service.  Once an 
InitialContextFactory Service was registered in the OSGi runtime the DIT 
was considered bootstrapped, up and running.  Now the Config Admin 
bundle was waiting for an InitialContextFactory Service as its service 
dependency and when it found one, the Config Admin then began offering 
all other bundles (ie components) like LDAP or as Enrique mentioned 
Kerberos it's Config Admin services.  Single or multiple instances of 
these services would be started depending on the configuration in the DIT. 

The Config Admin is considered the center of the universe, the DIT it's 
core.  All planets and celestial bodies (aka bundles not only ADS that 
needed configuration services) revolved around this sun.   The runtime 
configurations of most of the running services as well as the LDAP 
service itself is now under the control of an LDAP client.  Prospero 
would be proud.

The big problem with this first OSGi impl was the hard coded nature of 
the boot strap to get that DIT and the InitialContextFactory Service.  
Spring was not used.  Second prototype tried alternative configuration 
with property files but with the advent of Spring-OSGi I thought that it 
offered the best way to leverage what we were already using for 
configing the ADS.   Unfortunately Spring is really a developer wiring 
language and are not really a configuration language suitable for system 
administration.  This is even more true  for Spring OSGi as the Spring 
dev folks have now embed the Spring configuration files within the 
jar/bundle of the component.  Not impossible but it makes it tough to 
config that file when it is in a component jar. 

So with the latest OSGi impl I tried to kludge my way out of this fix by 
offering an external properties file.  Here is a snip from the 
server.xml which now for Spring-OSGi must be embeded in the component jar. :

<!-- This configuration file will reside within the bundle. To change 
the configuration
    an external properties file called in the working 
    can be used to override the exposed property values. -->
    <bean id="propertyConfigurer"
        <property name="location">
            <bean class="">
                <constructor-arg value=""/>
        <property name="ignoreInvalidKeys" value="true"/>

Here is what an external file would look like. (Note 
that the bean calling this file was a Spring OverrideConfigurer so I can 
override configuration properties values using a simple form of 
hierarchy to address the specific default properties in the server.xml):
examplePartitionConfiguration.contextEntry=objectClass: top objectClass: 
domain objectClass: extensibleObject dc: verticon

<Radical thoughts>
"Imagine there are no configuration files.  It's not hard to do."  - 
John Lennon.
If/when we were to go to OSGi I think that scheme should be 
reconsidered... Wouldn't it be nice if there where only components - I 
mean just jars?  No external files.  To configure our (and third party) 
components we would use our DIT to persist them. Configurations would be 
in it and wrapped with an industry standard API like the Config Admin.  
People wanting to use a component offering a service like LDAP would 
just add the component and configure it via LDAP itself or via Config 
Admin again with the persistent config stored in the DIT. 

Unfortunately we would still have that bootstrap problem.  But what if 
our sister project LDAP Studio would offer a bootstrap configuration 
UI?  Like Ole suggested earlier?  Then we could model this core 
configuration model with EMF and then generate the majority of the ui 
editor as a companion plugin for LDAP Studio.  The serialized core could 
then be repackaged with the component or if we wanted to be more 
conventional left as an external config file.  If we are using Spring 
only for config reasons it could go then go away.

</Radical thoughts>

> I'm totally fine with living with what we have to get SASL out the
> door.  And with Spring XML, you can have 2 (or more) beans in one XML
> file (we do that already).  The one place in the current code where
> everything comes together is still the ServerContextFactory.
> Enrique

View raw message