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
