Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding:from;
        b=q/wTeMFVMkPN6If652rdp0YyJ5eqOukOVkru7HSIJ+X5JpXeZpIZr5XPVeucvsJ6lo
         iP81Lego6ugI5jQNR5ckYS5/ICUUN+Rho1KO7Z1XwsReEQzUSu4TjS3zTjk+i/E/r4mD
         06rqZwKiP49XKj/mvMB790P42bxMR6wJoofUM=
Message-ID: <4920BD71.2070806@nextury.com>
Date: Mon, 17 Nov 2008 01:40:17 +0100
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Partition configurations [was Re: [CONF] Apache Directory
 SandBox:
 Draft - ... ]
References: <875958375.1226774880024.JavaMail.www-data@brutus>
	 <491F2800.1050504@apache.org>
 <491F4254.30507@labeo.de>	 <49205340.8060007@nextury.com>
 <49205887.90104@labeo.de>
 <f275eef10811161606r3eed1002q778f31c2cc6c71d7@mail.gmail.com>
In-Reply-To: <f275eef10811161606r3eed1002q778f31c2cc6c71d7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
From: Emmanuel Lecharny <elecharny@gmail.com>

Norval Hope wrote:
> Hi All,
>   
Hi Norval,

comment inline
> 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.
>   
Not sure I get a clear picture, but if it's just about separating 
partition's configuration in many different files to avoid having a big 
fat config file, then I agree : it's necessary. Tell me if I understood 
correctly.
> 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. 
Let's go back a bit backward. The very first version of ADS was using a 
typical java property file : key=value, that's it. Worked well, simple, 
and pretty verbose. But adding comment into it was just so easy ...

The someone suggested to use Spring 3 years ago, when it started to be 
more than over-hyped : it was over-used. (Ok, I'm biased). Later in the 
process of migrating to 2.0, XBeans was introduced in an attempt to 
"simplify" the configuration file.
> 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. 
Well, I have to say that as far as I sympathize with your concern, i 
must tell you that it's also a bit peripherical to the project. Not to 
say that we don't care, because we _do_, but because no decision has 
been made atm, and I don't think that we will make a choice in the next 
few months, neither in the next 6 months. And I'm pretty positive when I 
say it won't change before 2.0.

In fact, things are pretty clear : we don't have time for ditching this 
server.xml file now.

However, many of us are considering that the current configuration is 
too complex, and has many drawbacks. Sadly enough, there is no magic 
bullet. What some of us like with the 'config in DIT' things is that we 
will have a coherent system (LDAP from floor to the roof) . But this is 
obviously not that simple...

<my own opinion>
Let's be clear : when debugging the server, Spring is a PITA. You have 
to *know* what is initialized by looking at the server.xml file to be 
able to follow the initialization path. When something goes wrong - and 
trust me, it happens all the time - you are FU big time. I spent more 
than one hour last friday with a server blowing chunks just because some 
part of the server.xml was doomed, due to some classpath issue.

When you combine it with xbeans, it's even worse. You have no f*ckinck 
direct clue about which class is associated with an alias, as all of 
that is hidden in a 1.0 file (yes, the file's name is 1.0 !!!), deeply 
buried into a directory somwhere (just dig...). And as it's absed on 
annotations, you also have to drill the inheritence to actually _know_ 
which values are initialized. Of course, if you are in love with XSD, 
you can have fun with a XSD file... I'm not _that_ deviant ;)

So bottom line : I deeply regret the old property file... Conf in DIT is 
to me a way to come back to something I can handle : text file without 
one or two level of indirections (assuming that the conf is stored into 
a text based partition, be it a LDIF file or whatever). FYI, OpenLdap 
configuration can now mainly be stored this way.

But this may be just me ...
</my own opinion>
> 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. 
Let's call a cat a cat : what we want is a plugin approach : a new 
custom partition should be a plugin, and you should be able to separate 
this custom partition configuration from the existing server 
configuration. Am I on the same page ?
> 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).
>   
I think we can reach a kind of concensus here, if we consider that it's 
just a matter of starting the server. Considering that when you use an 
embedded server, you don't have to deal with all this Spring+Xbeans 
crazyness, it's obvioulsy possible to define a somution where :
- you can use Spring if necessary
- OR use a simple property file if you like it
- OR store the configuration as LDIF file
and still having one simple system where the conf is stored into the 
DIT, once the server has been launched (ie, the conf is loaded in 
memory, and addressed through the LDAP API).

I see no reason why we couldn't reach this decoupling between 
configuration system and the running server. But in any case, I agree 
with Norval that XBeans introducing some more coupling, adding some 
annotations in the code.
> 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.
>   
Same conclusion here...

thanks Norval !

-- 
--
cordialement, regards,
Emmanuel L�charny
www.iktek.com
directory.apache.org