Go on buddy get jiggy with it. Alex
On 9/28/07, David Jencks <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > >
