directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Partition configurations [was Re: [CONF] Apache Directory SandBox: Draft - ... ]
Date Mon, 17 Nov 2008 01:02:50 GMT

On Nov 16, 2008, at 4:06 PM, Norval Hope wrote:

> Hi All,
> Just wanted to throw in some comments/observations from the
> prespective of a Virtual Directory implementation which sits on top of
> AD. In this kind of use-case it is completely necessary to discover
> connector implementations (aka custom partitions) dynamically at
> start-up (like a poor-man's OSGi implementation which requires a
> restart - as I too have had proper OSGi connector bundles on my list
> of TODOs for ages). For this purpose I have used Spring's
> FileSystemXmlApplicationContext's ability to discover files in jars on
> the the classpath, using a command line arguments like:
> "server_jcs.xml "classpath*:conf/connector.xml" (where each
> connector's .jar file has a specialized conf/connector.xml in it which
> configures only settings for the connector itself). Hence this
> approach is definitely possible, and desireable for cases like mine
> where connectors come and go regularly.
> Secondly I get extremely nervous when I hear "use the DIT and ditch
> Spring" as has been mooted a number of times on the ML before, unless
> the DIT is merely a used as a storage place for XML orginally taken
> from "live" connector.xml files. This is because the content of my
> connector.xml files are custom POJOs, many of which are even specific
> to a single connector implementation, and hence I have no interest in
> reworking all this config into a heavy-weight custom LDAP schema when
> Spring is doing exactly the right job for me currently. When it comes
> to custom partition implementations I don't think my use-case is
> atypical, i.e. I would expect it to be the norm that they will
> generally require custom configuration too, and therefore think the
> combination of Spring and custom POJOs is a perfect match. As I
> mentioned earlier, having an option where the config stays as XML but
> can optionally appear as an attribute value in the DIT (presumably for
> the parition itself) may allow the best of both worlds, keeping easy
> Spring configuration but still allowing replication etc. For the same
> reason (and the fact I have to remain backward compatible) I'm also
> not keen on the extra work required to tidy up the config files using
> XBeans, while the Spring syntax may not be as compact it is easy
> enough to understand (and comes with a 0% maintenance load - this
> additional load seems to me to be the price you pay for the more
> compact XBeans synatx).
> So in summary - in my world-view fluid configuration is a must. I want
> to be able to change just configuration JavaBeans and a few associated
> settings in XML. I don't want to have additionally update a
> heavy-weight custom configuration schema and/or XBeans wrappers.

I can't say I regard xbean-spring as an ideal solution, but I don't  
really understand why people think its any harder to use than plain  
spring.  Unless you are changing the tree structure of the  
configuration javabeans you don't even need to change the  
"annotations" to get the updated schema, just build.... at which point  
you can use your favorite xsd-aware editor to check on the validity of  
your xml configuration before you start up the server and discover you  
misspelled an attribute name.  What am I missing?

But, if you don't want to use it for your extensions, you can  
certainly mix normal spring and xbean-spring xml in the same xml  
configuration file.

david jencks

> Cheers
> On Mon, Nov 17, 2008 at 4:29 AM, Stefan Zoerner <>  
> wrote:
>> Hi Emmanuel,
>> Thanks for snapping in the discussion! I will add some of your  
>> valuable
>> information to the documentation.
>> Emmanuel Lecharny wrote:
>>> I will try to add some clarification about those partitions,  
>>> because it's
>>> not really something trivial.
>>> First, let's assume we are talking about 1.5 here.
>> Yes we do.
>>> A partition is nothing more than, to take an analogy, a mounting  
>>> point on
>>> a Unix filesystem. It has a root name (a DN in our case, and the  
>>> underlying
>>> storage can be whatever we want, byt from now on, a JDBM based  
>>> storage (we
>>> can perfectly set a partition to use BDB JE, as Kiran implemented  
>>> it, or
>>> Oracle, or MySql, as some of our users did).
>>> The main difference is that a partition _must_ be associated with an
>>> entry. It's npt different from what you have on OpenLdap anyway.
>>> So let's sum up. You need :
>>> - a name ("dc=example,dc=com", for instance)
>>> - an alias in the configuration file ("example", here)
>>> - an underlying storage ( <jdbmPartition id="example"...)
>>> - and an entry which has to be injected in the server :
>>> dn: dc=example,dc=com
>>> ObjectClass: top
>>> ObjectClass: domain
>>> dc: example
>>> and that's pretty much it.
>> As far as I understand it, the alias in the configuration file is not
>> necessaryeven a configuration file is not necessary (if you run  
>> ApacheDS in
>> embedded mode).
>> The entry representing the name/suffix has not to be injected into  
>> the
>> server, if the underlying partition implementation already has this  
>> entry.
>> Emmanuel, would you please take a look at my minimal partition
>> implementation,
>> which simply carries one entry
>> dn: ou=helloWorld
>> objectClass: top
>> objectClass: organizationalUnit
>> description: hello, world
>> description: a minimal partition
>> ou: helloWorld
>> It has not been injected, because it is the only one it has, and it  
>> is
>> created during the init-method.
>> Any feedback would be helpful. Is this a valid partition (and yes,  
>> I have
>> created something completely useless from a storage point of view  
>> -- it is
>> just a starting point for all the guys trying to write their own  
>> partition).
>> I already have some questions. But I plan to stabilize my minimal  
>> example
>> first in order to have something for the docs. In have a second  
>> example,
>> which publishes the and their values as a tree in  
>> order to
>> show more methods from the partition interface.
>> Greetings from Hamburg,
>>   Stefan

View raw message