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.
thanks
david jencks
Cheers
On Mon, Nov 17, 2008 at 4:29 AM, Stefan Zoerner <[EMAIL PROTECTED]>
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
