directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: [ADS 2.0] Detach JNDI from ApacheDS
Date Tue, 05 Sep 2006 17:39:04 GMT
We will definetely support JNDI with an adoptor. It's really not a
matter. The problem is how we will design our new architecture :-)

On 9/5/06, John E. Conlon <jconlon@verticon.com> wrote:
> 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 :
> > > http://www.openldap.org/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.
>
> John
>
>


-- 
Ersin
Mime
View raw message