directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: Partition configurations [was Re: [CONF] Apache Directory SandBox: Draft - ... ]
Date Mon, 17 Nov 2008 10:41:57 GMT
Hi Emmanuel, comments inline ...

On Mon, Nov 17, 2008 at 11:40 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>> 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.

Yes, it is about separating partition's config files out from
server.xml, but also bundling inside the jar for each connector (aka
custom partition). Every connector's .jar includes a
"conf/connector.xml" and Spring's FileSystemXmlApplicationContext
magically loads the config for all the custom jars found on the
classpath via the "classpath*:conf/connector.xml" syntax. Hence
removing support for a custom connector requires exactly a) removeing
it's .jar and b) restarting AD.

>>
>> 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.

I'm personally quite impressed with Spring and its ability to
configure any JavaBean, even custom ones used by extensions to the AD
core (or even my VD core) code. When the config settings are
completely fixed there may be no need to use Spring's IoC power, but
it brings very valuable flexibility in a plug-in type environment.

>>
>> 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.
>

I understand my usecase maybe seem a little left-field for AD at the
moment, but I think flexible configuration is always likely to be
useful when writing custom partition implementations. It may be
preferrable to split config into some standard settings (like the
injected DN etc) and a separate more flexible text fragment found
elsewhere, which I have no problem with as long as the latter fragment
can be supported in some way.

At any rate, I'll have to maintain my current config approach no
matter what direction the AD core heads off in. As such, I'm not
trying to force AD in one direction just to suit my purposes. My
config / connector loading functionality is currently a custom
extension I've made to AD and I can maintain it as such. Just wanted
to chime in with another usecase for consideration...

> 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>

I understand what you mean, I have had some problems debugging Spring
too. Also XBeans aims to solve a problem (concise more readable XML
representation) which I'm not much interested in - we will probably
end up with 30 or so connector implementations eventually and there is
no way I want to maintain either a) 30 custom config schemas or b) 30
XBean views of the config requirements for each.

>>
>> 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 ?

You are on the same page. I go further and say a custom partition is a
single .jar file including implementation and default configuration,
although I allow the default configuration to also be overridden by an
XML file on the filesystem too. Long term I want a custom connector to
be an OSGi bundle so that they can be hot-deployed without restarting
AD too. If the configuration is read from the .jar / bundle and
pusblished into the DIT somehow, then that's fine by me.

>>
>> 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).

Sure - just trying to register a +1 for solutions which are still
compatible with your first option (Spring config), even if it is not
directly implemented.

>
> 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.
>>

Mime
View raw message