Enrique Rodriguez wrote:
On 3/15/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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.
History
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.
Rework
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 server.properties in the working
directory
can be used to override the exposed property values. -->
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
<property name="location">
<bean class="org.springframework.core.io.FileSystemResource">
<constructor-arg value="server.properties"/>
</bean>
</property>
<property name="ignoreInvalidKeys" value="true"/>
</bean>
Here is what an external server.properties 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.name=verticon
examplePartitionConfiguration.suffix=dc=verticon,dc=com
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>
John
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
