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.