directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject [ApacheDS] Configuration Beans
Date Wed, 18 Jul 2007 03:53:14 GMT
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.


View raw message