directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [ApacheDS] Big Bang Cleanup
Date Fri, 28 Sep 2007 23:22:22 GMT
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?

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

View raw message