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