directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ADS 2.0] Detach JNDI from ApacheDS
Date Mon, 04 Sep 2006 07:18:24 GMT
Trustin Lee a écrit :

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

The beauty of LDAP is that you can work with JNDI, Novelm API  (jldap : or even our own new API. We can keep the 
JNDI approach, because it's common to many application, and dropping it 
would be seen a little bit questionnable by our current users (I'm 
thinking of Geronimo)

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

We can provide both, in my opinion. JNDI is an interface...

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

This is a possible move. Alex ?

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

+1 for moving to OSGI. This is a must.

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

We really need this embeded mode. Many application will benefit from it 
: no more complicated firwall configuration to let LDAP go through, no 
more need to start the server before the application, etc. It's a little 
bit like Jetty. Sometime, it's better to embrace everything in a simple 

> Was this too radical? :)

No, not too much ... I thought you would propose to switch to C# (I 
would called it a revolution then :)


View raw message