directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [ADS 2.0] Detach JNDI from ApacheDS
Date Mon, 04 Sep 2006 06:22:00 GMT
On 9/4/06, Trustin Lee <> wrote:
> Hi,
> Yes, I know this is a very radical approach, but I think this is mandatory
> to accelerate our development.
> JNDI is an abstraction API for all kinds of directory services.  LDAP is a
> part of the list.  From my experience, JNDI is not really the best API to
> access an LDAP server.  It can access the LDAP server, but not gives us the
> best convenience from the viewpoint of the API user.  And we're using JNDI
> Name and DirContext interface to program our internals.  That's why we need
> a new API which perfectly fits into LDAP.  By doing that, we can program our
> interceptors and partitions more easily mapped into LDAP operations rather
> than JNDI operations.
> Of course, this change will take away the advantage of embedded mode unless
> we spend more time to create a bridge between JNDI and our API.  But I think
> our primary concern is to provide a high quality LDAP server whose internals
> are highly optimized for LDAP, not to provide a JNDI embeddable LDAP server.
> Here's my suggestion:
> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1 to
> LDAP operations rather than JNDI operations.
>    * Core/ServerDirContext will be removed in this process.
>     * ServerStartupConfiguration should be merged into StartupConfiguration
> and embedded mode should go away because we can just disable the LDAP
> service later when OSGi is adopted.

I completely agree on 1:1 fit. I also prefer pure LDAP operations to
optimized operations (like the modify operation which takes a single
ModificationItem instead of an array, or lots of kinds of search
operations). Those optimized operations make services writing hard and
causes lots of repeated code (and also untested code because we rarely
use some of them).

> 2. Migrate to OSGi framework
>    * All protocol services will be provided as OSGi bundles and should be
> plugged into ApacheDS dynamically.  Because we don't have any embedded JNDI
> provider, LDAP protocol connection to loopback device will be used
> temporarilly.
> 3. Support an embedded mode
>    * But who will ever use DNS or other services without LDAP provider?  The
> only advantage of the embedded access is the small performance gain which
> might not be that important in distributed directory services.
> Was this too radical? :)

No of course. This is something we discussed several times. Alex had
recently started a thread about getting rid of JNDI.

I think we also need to provide a clinet API again as a 1:1 with LDAP.
I am not sure about how this might overlap with the server API but I
think they will somehow differ.

> Trustin
> --
> what we call human nature is actually human habit
> --
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6


View raw message