directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <>
Subject Re: [IMPORTANT] Status of Apache Directory
Date Thu, 02 Nov 2006 23:15:45 GMT
On Thu, 2006-11-02 at 14:14 -0500, Alex Karasulu wrote:

> =========
> OSGi Plan
> =========
> I have no idea what is going on with the OSGi work. 
>  It seems like John 
> Conlon is the only one left working on it now.
> There are no updates to the community and very little knowledge sharing 
> about this.  We need more status on this if anything.

Submitted a 'Plan' at

... suspect it is the wrong location now after all the moves and

As mentioned in the document the initial ADS OSGi effort is focused on
Structurual Componetization or to use more mundane terms - dependency
management (aka trench warfare), but what I did not detail is that much
of the current OSGi dev and testing work is also dealing with service
dependency frameworks and configuration management.

So here as some of the details ---

Looking at what we need (and IMHO a heck of a lot of other people in the
OSGi world will recognize they need as well) from a bottom up

-1. We need to deprecate the trunks/apache/osgi
 0. We need a few of the common depenedencies we use throughout
apacheds/mina wrapped as OSGi bundles.
 1. A bundle to offer the Mina libraries, 
 2. A bundle to offer apacheDS libraries and a jndi Backend service,
(This bundle must offer a way to do bootstrap configuration of the
backend server as well as offer dynamic schema loading.)
 3. A bundle (or bundles) to offer all other shared libraries needed by
the higher components,
 4. A bundle to offer an apacheDS implementation of the OSGi
Configuration Admin service. (When we have this we will draw much
attention. Press Release time...)
 5. Bundles offering various protocol services

-1. trunks/apacheds/osgi
The current OSGi work in trunks/apacheds/osgi held the seeds of what we
have been experimenting with to date, but that said it is pretty
stagnant and dependencies of the projects are really a mess. (I have
previously submitted patches and/or suggestions but these have not been
applied or acted on. )

It retarded our efforts for the osgi parent and sub projects to be in
this subdirectory of apacheds. (Easy to say now in hindsight.) Ideally
OSGi support should be integral to each pom as an annotation only, not
existing as a separate project, unless like our ConfigAdmin it actually
implements an OSGi interface or in the case we are forced to wrap
libraries that we don't or can't control.(more on that later) 

I found it easier to keep my testing work in my local environment for
now. (Would prefer to use an ADS sandbox where I would expect a welcomed
appearance of adult from time to time for code review.)

0. Common libraries
These are the libraries we need available within the OSGi runtime, but
we do not control them. If they are not OSGi someone has to make them
OSGi. The maven folks are looking at creating a new release of maven
that will do this for all maven archives automatically. Unfortunately it
is not there yet. There is always the home enough people with a need
will get together and collectively do this. There is a 'movement' over
at felix for doing this that seems staled. All our other efforts depend
on this. If and when the Mina folks are ready to move and we are blocked
here I will push it myself at felix or come up with a fast set of
wrapper projects like we had in the trunks/apacheds/osgi projects but
with cleaned up dependencies.

1. Mina
>>From an OSGi perspective Mina should be easy to do. It is basically a
wrapper effort. But the question has always been - one or multiple
wrapper bundles?  A single pom will do it. Had one and even published it
to the Mina dev at the end of August (See topic 'MINA as pure OSGi
bundles?' in mina-dev). So what is the problem? Guess I got a greedy - I
wanted less! I wanted no OSGi project for Mina. Right, Instead of a
separate project, I just wanted to add the metadata to one or more of
the Mina poms and let the OSGi plugin do its thing. After all that is
the right thing to do if you control the code. But the problem was with
Mina packages being spread across multiple projects, the OSGi runtime
would take 'exception' to the fact that the various bundles were not
offering all the classes from the advertised packages.  

Much is still being debated at mina-dev regarding 1.1.0 and with some
hope (from an OSGi perspective anyway) new ideas for coming up with an
optimized java5 build for the mina 1.0.0 api. If and when that happens I
would propose that we add an mina-integration-osgi project to that

BTW - Just sent to Jira a prototype pom.xml for such a project.
See for details.

2. Backend
Current test bundle is based on the OSGi servicebinder technology, but a
new prototype I concocted two weeks ago is based on the new spring-osgi.
Yes that right. The Spring 2.1 release will be OSGi enabled! Just doing
testing this week with it and should have something more concrete by
next week. (I sure was hoping for something like spring-osgi to fall out
the sky and help use with our bootstrap config problems - and now it

4. Configuration Admin.
Current test bundle is also based on servicebinder, after backend is
retrode to spring-osgi will try the same here. Our implementation has
several design features(?) that require more of a discussion which of
course requires an interested group of parties to exchange ideas.
Hopefully as we gain momentum this will change.

5. Protocols
Have done nothing myself here, but expect to rapidly follow once
ConfigAdmin is done. Enrique's old code from the trunks/osgi should once
again provide valuable.

- John

View raw message