directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: [ADS 2.0] Detach JNDI from ApacheDS
Date Tue, 05 Sep 2006 17:30:10 GMT
On Mon, 2006-09-04 at 18:51 -0400, Alex Karasulu wrote:
> Emmanuel Lecharny wrote:
> > 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...
> > 
> Yeah I think we can provide both.  Trustin was referring to a bridge 
> before and I agree.
> The LDAP protocol provider would not use this bridge however.  It would 
> use the LDAP specific API instead.
> Other protocol providers that back their information within ApacheDS can 
> use the JNDI bridge.
> >> 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 ?
> Yeah I think can.  What I recommend is small refactorings to slowly 
> bring us towards this or a similar goal.  First we can decouple the JNDI 
> provider from the core.  We can also decouple the configuration from the 
> core as well.  By doing these things we will arrive at a better 
> structure and then will have better vision to figure out what needs to 
> be done next.
> >>
> >> 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.
> Hmmm I don't know about this.  I think these guys can use the bridge and 
> not have to go through the wire which would slow things down.  Trustin 
> was this lookback thing related to conversations we had in the past over 
> ClassLoader issues and instances of the DirectoryServer?  My memory is a 
> bit hazy here.
Well we do have an embedded JNDI provider - it is still in its infancy
but lives within the trunks/apacheds/osgi.

Currently running an 'embedded' ApacheDS within the same VM as my
application using a version of the provider (modified) but the cool
thing is: with the magic of OSGi and 'JNDI' my 'application' does not
know anything about ApacheDS.  ApacheDS is a set of OSGi bundles that to
my application bundles, offer an OSGi service (InitialContextFactory).
The virtual machine also runs an LDAP protocol bundle that allows LDAP
clients to change the backend configuration of my app.  If I wanted I
could (at runtime) stop the ApacheDS and load an alternative
InitialContextFactory that uses a LDAP service on another machine. 

My app does not go through LDAP but JNDI. Using LDAP for clients access
to modify the configuration. Making an alternative LDAP interface is
fine if necessary for internal optimization but we should still support
JNDI higherlevel access.


View raw message