directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject [ApacheDS] Big Bang Cleanup
Date Fri, 28 Sep 2007 22:19:45 GMT
Hi all,

I just want to report on some interesting conversations on IRC and IM that
I've had recently
and the clear conclusions it has led a few of us to.  First let me state the

The server is tightly coupled to JNDI from the protocol provider down into
the core.  The intent
to use JNDI originally came from the idea that people are used to JNDI and
so if used as the
wrapper API around the server it would ease the learning cure.  Furthermore
using JNDI interfaces
to achieve this made sense since it would reduce the transformation overhead
when embedding
the server making it more efficient.  Furthermore when used in conjunction
with stored procedures
JNDI would allow procedures to be written outside of the server and (in
theory) tested outside of
the server just by switching the JNDI provider from the SUN LDAP provider to
the embedded LDAP
provider in ApacheDS.

Although the idea to use JNDI to reduce the learning curve is a good one the
implementation which
coupled the server internals with JNDI details is causing us serious
problems.  The JNDI provider
would have been better implemented as a wrapper around internal API's that
are more aligned with
server side LDAP centric data structures.  Because they are not one must be
aware of JNDI and the
complexities of interchanging from JNDI environment variables to and from
the core data structures.
The entropy is high and results in a lot of one offs in the code.

I have always wanted to fix this problem but never had the bandwidth to do
it. It just stuck and rooted
itself as we built upon this foundation.

Years ago Trustin Lee had expressed the desire to strip out the JNDI
coupling as well but he too ran
into the same hurdles.

Enrique Rodriguez had other issues revolving around the side effects of JNDI
in the core while dealing
with an OSGi based version of the server.

A few weeks ago David Jencks expressed his dismay over having to use JNDI to
configure the server
and wondered why we do not wire the components of the server directly.

Recently Emmanuel Lecharny and I paired up to review the authentication
subsystem for some clearly needed
changes.  However at some point we realized that JNDI is excessively
complicating the simple picture
that should be there.  So we stopped after some point.

Later in the day today I had a conversation with Chris Custine about these
problems on IM. We reviewed
the problems and thought about what it would take to strip out JNDI while
removing these configuration
beans getting in the way of directly wiring up the server.  We reached
similar conclusions.  We're going
to have to bite the bullet on this one at some point or another if we intend
to build on the architecture
without loosing time and energy dealing with the trouble that this JNDI
coupling brings with it.

Chris said he's on board with just doing it.  So am I.  David and Emmanuel
wants to as well but we need
some confirmation from them.  With the recent discussions to delay the
2.0release I think this is a great
time to just take care of this problem once and for all.  Also now we have
many more hands and minds
to do this right relatively quickly.

While doing this we're going to break many things. It's not going to be
pretty.  So I recommend
switching to a temporarily branch so we're not caught with broken builds on
the trunk.  Then we can
immediately merge the changes back into the trunk and delete this branch.
No need to worry about
the trunk running away from us since most of us on this branch will not be
working on it and well
the branch should last at most 2-4 weeks.  I'd like to get it done sooner
but I am afraid the fallout from
the changes will be very significant.

I am going to just branch now and start working on this.  If yall want to
join me then let's go to town.
I'll post the SVN URLs to this tread.  And of course we can have the team
review where we go before
merging back but then again most of the ApacheDS active community will be in
this branch anyway.



View raw message