[ApacheDS] Configuration Beans

[Alex Karasulu <ak...@apache.org>]

David Jencks asked an interesting question on the Configuration in DIT
discussion thread.  Chris
Custine also echoed the same essential message:

Why do we have these configuration beans instead of just using Spring to
wire together
ApacheDS components directly?

In the CiDIT discussion thread I said that I don't know but I think this was
just my lazy self talking :).
The reason is a long one and there are a few of them, and they're not all
for the right reasons.

In the beginning we used JNDI purely to carry the configuration as keys
within the JNDI environment.
This sucked big time especially as the configuration grew to include more
options within the
server and as more protocols were added.

Then Trustin refactored the server a bit and one of the things he worked on
was to build composite
configuration objects to hold associated groups of configuration information
instead of all these
nasty JNDI keys.  He opted to use Spring to achieve this goal.  This is how
the server.xml came
to be.

I figure Trustin could not easily exploit Spring's ability to wire up the
components of the server
directly since much of the initialization code strewn all over the server
was inside various components.
The best he could do within the time allotted was conglomerate these keys
into complex objects
and use Spring to instantiate and populate them from the server.xml.

A few nights ago Chris and I had a very good conversation offline.  He (a
Spring lover) was trying
to show me (a Spring hater) that Spring could be exploited much more to
reduce the amount of
work performed by the server.  He basically stated the same thing that David
was saying as well.
During the course of this conversation with Chris I was describing how we
have two ways to
package the server: embedded and standalone.  In both cases some information
some information
is needed about how the wiring is to be done to guide the initialization
code in the server.  In the
embedded case these configuration beans are assembled programmatically and
pumped into the
JNDI provider.  In the standalone case the beans are built by Spring and in
the same fashion pumped
into the JNDI provider.  At some point we realized that we could just use
Spring in both cases even
in the embedded situation in which case users would only need to point the
server to a Spring xml
configuration file.  Even though we can do this I think it's the wrong thing
to do.  Let me explain
why after explaining the approach I would like to take.

I would like to factor out the dependence on these configuration beans in
the core.  To do so the
initialization code that depends on them to guide them in their task of
wiring the server together
must be extracted out of various parts of the server.  This initialization
code is all over.  By
extracting out the code that wires the server together from actual runtime
components and data
structures needed for solid state operation after initialization we will be
enabled to use any kind
of container to wire up the server.  Only under these circumstances will we
be container agnostic
and only under these circumstances will we really be able to exploit the
capabilities of Spring or
any other container.

So until this point there is no way we can really leverage a container
properly.  Afterwards we
have the liberty to choose any container but Spring is not first on my
list.  I'd rather see OSGi
used instead.  Hopefully by then the OSGi community is ready with the tools
to support such
an effort.  Namely I'm waiting on solid low overhead in situ testing
capabilities for OSGi services
before I take this leap of faith.  However IMO it's just premature to even
discuss this topic until
the other problems mentioned above are remedied.

Alex

Re: [ApacheDS] Configuration Beans

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

I won't comment the whole mail, but just adding a point wich seems
essential to me :
 we are discussing about using a container or not, with people
thinking we should use Spring differently, and Alex saying this is not
possible, and even that Spring won't be the best choice.
Alas, nobody but Alex knows which is the exact initialization process,
(ok, I must admit I know a part of it), so discussion about using a
container to start the server is a dead end, as only one person knows
the rationnals. What I suggest is that we describe the init process in
a way anyone can have a clear understanding of how it works (I have
started it months ago, and I didn't had time to go very far, but now
it seems urgent to me)

Regarding CiDIT, which is related, the problem is quite the same : we
don't exactly know what should be put in the DIT, and how to handle
it. It would be interesting to list all the configuration which can
fit into the DIT, compared to what should stay in a file (be it a
Spring file). Some people are reluctant to ditch Server.xml, and I can
understand their position.

>From my POV, if we put everything in the DIT, then we must have a
standard way to inject and modify those informations. I think that
LDIF or DSML files should be used, because it's easy and standard to
inject such files in an LDAP server. Otherwise, we should also provide
very simple command line scripts to get/set configuration elements,
with may be a CL interface to do so (I don't know for you, but I don't
want to type ldapadd with all the cryptic arguments each time I want
to store a new parameter ...)

We may have to discuss this before starting writing any piece of code.

wdyt ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com