I'm definitely in favor of this and very much want to help out. I
have some other stuff I have to get done before I can spend much time
on it... hopefully I can finish that up this weekend.
So would it be appropriate to apply my xbean-spring and no-
InterceptorConfiguration changes to the new branch?
thanks
david jencks
On Sep 28, 2007, at 3:19 PM, Alex Karasulu wrote:
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 problem:
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.0 release 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.
Thoughts?
Alex
