directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: [ApacheDS] ML Update on Skype Conference Call
Date Tue, 14 Mar 2006 15:42:23 GMT
John E. Conlon wrote:
> On Tue, 2006-01-10 at 09:55, Alex Karasulu wrote:
>>Also we don't have enough OSGi experience on board.  We welcome you to 
>>join us in to help with the OSGi effort.
> I am willing lend a hand to Enrique. I wait for the 1.0 RC1 and then the
> 1.1 branch to form first.
> John

You ready for this?  The 1.1 branch has formed, so I'm preparing to
refactor it to use OSGi.  I did much of this work over a year ago, so it
should be some basic refactoring and package renaming to get it to boot

After that, I see 3 areas of work that need more than minor refactoring:

1)  I'd like to move CM, Prefs, and UA over to Felix.  This is mostly 
work and discussion for the felix dev list, but these services are in 
the Directory repo and we've long since discussed moving them over. 
They'll need an M2 update, basic dep updates (refactoring, renaming 
packages), and eventually updates to be R4-compliant.

2)  Not all of the directory-backed Config Admin store was implemented; 
I only did what I needed to make directory work.  Basically, some 
straightforward CRUD-type operations need to be quickly coded.

3)  In the move to the OSGi-standard Config Admin service, some 
decisions will need to be made w.r.t. transitioning the current Spring 
XML configuration file.  All the protocol providers I wrote (Kerberos, 
NTP, DNS) work fine with Config Admin.  I have Strategies in place to 
use the flat XML config or to look to Config Admin.

However, the core JNDI provider and the LDAP wire protocol are not 
updated to use Config Admin.  Likely, the LDAP protocol provider can get 
refactored to operate like the other protocols, to receive port/inet 
binding and other config from Config Admin easily.  This leaves the core 
JNDI provider.  The JNDI provider can continue to use an XML config and 
we can work to DIT-back as much config as possible and leave open the 
possibility of a boot props file.  Although, given the presence of the 
system partition, I'm not sure what can't go in the DIT.


View raw message