directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Big Bang Cleanup
Date Fri, 28 Sep 2007 23:34:57 GMT
Go on buddy get jiggy with it.

Alex

On 9/28/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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
> >
> >
> >
> >
> >
> >
>
>

Mime
View raw message