directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Implementing another backstore (backend)
Date Sat, 29 Jan 2005 20:29:02 GMT
Nikola Ivancevic wrote:

> Hi
> I am working on an ISP-centric application. Currently, I am trying to 
> find out the most suitable way to implement LDAP interface for the 
> app.  Few days ago I 'discovered' the ApacheDS project and started to 
> examine it. After reading docs and looking over the source, I think 
> that ApacheDS might be an elegant solution for me. And I 
> could not find any attempt of implementing a mechanism for another 
> backstore 'plugin' (so far), I am thinking of the way how to do that. 
> I'm willing to contribute to the ApacheDS, so it would be nice if I 
> could implement that extension in the way that is most native to the 
> rest of ApacheDS project.

Wondering what your requirements are.  I would think the default backend 
would suite most needs out of the box.  Mind describing your situation a 
little more in detail?  Are you trying to get at some nonstandard access 
model and expose it via LDAP? If so this might be a good move for sure.

> So, any hint out there?
Well Nikola you can easilly write a backing store implementation and 
snap it into the server having it attached to a context within the 
namespace.  Take a look at the following interfaces here...these must be 
implemented.  Then plugging in your backend and using it becomes cake.


      or here in javadocs:

The ContextPartition interface is what you want to implement and that 
extends the BackingStore interface with links to follow.  It's a simple 
backing store which adds a single method getSuffix() to figure out where 
on the LDAP namespace this store (partition) is attached.  The DN 
returned by getSuffix() is the base where entries at and under this DN 
are stored in this partition.  So if the suffix is dc=apache,dc=org we 
would store this entry and its descendents within that 'context' 
partition.  Here is the real meat to the interface but this in itself is 
very simple and straight forward.  It's all about doing CRUD ops on 
Attributes objects.  As many JNDI interfaces as possible are utilized in 
specifying this contract so you don't have to learn anything new if you 
already know JNDI.

    or here in javadocs:

One last note.  You need not worry about anything but storage.  All 
other services are built on top of this using interceptors which 
introduce aspects like authorization etc.

If you are interested we'd love to try and build a prevayler based 
backend.  Personally I have no time but I don't mind overseeing it and 
helping out if you are interested.  This would really be cool for fast 
in memory stores like the system backend rather than using a btree based 
store with lots of cache.


View raw message