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 00:06:50 GMT
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.

Cheers


On Mon, Nov 17, 2008 at 4:29 AM, Stefan Zoerner <stefan@labeo.de> 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,
>
> http://cwiki.apache.org/confluence/display/DIRxSBOX/Draft+-+How+to+write+a+simple+custom+partition+for+ApacheDS
>
> 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 System.properties and their values as a tree in order to
> show more methods from the partition interface.
>
> Greetings from Hamburg,
>    Stefan
>
>
>

Mime
View raw message