Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=r1ccMoEvs3YxHKQuTJotJXhqKdPDmdVX7d5ESQA7Ajs7/uSkN/uaz8xU8QHK3xwnOXbIdbgYCAj4+MVOpicAAW5f5FW95cC2gXj3zhV0jTi4TNh1qQ/bHTYSTLvjsascyxcCXsSsyztz2l8CT5UDmttKhXSEG6aEx5007W0H/bA=
  ;
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <a32f6b020709281519t465c961eoabfff6b80156c0c1@mail.gmail.com>
References: <a32f6b020709281519t465c961eoabfff6b80156c0c1@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DA3CBC71-389C-45A2-9DCC-A21C1C957609@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: [ApacheDS] Big Bang Cleanup
Date: Fri, 28 Sep 2007 16:22:22 -0700
To: "Apache Directory Developers List" <dev@directory.apache.org>

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
>
>
>
>
>
>