On 6/8/10 2:51 PM, Guillaume Nodet wrote:
I don't have much knowledge of DS really, but in order to make things run
smoothly in OSGi, the first step is obviously to turn those into OSGi
bundles.
Karaf comes later if you want to use it as your runtime container instead of
using your own org.apache.directory.server.UberjarMain + everything that
Karaf provide.
Turning ApacheDS jars into OSGi bundles should be relatively straightforward
if there is no shared packages, which means each jar contain a set of
packages, but those are different (you can't find classes in the same
package in different jars). This would be the main problem (though there
are some ways to still do that in OSGi).
A first step should be easy and mostly consist in:
* defining a set of properties in the parent pom (such as the camel.osgi.*
in https://svn.apache.org/repos/asf/camel/trunk/parent/pom.xml)
* change the packaging of all jars to bundle, and define the properties
that need to be overriden (usually the exported packages as in
http://svn.apache.org/repos/asf/camel/trunk/components/camel-csv/pom.xml)
It should be easy but will certainly need to be refined over the time.
A second step is to provide a good osgi integration, mostly if / when you
have some discovery mechanisms such as pluggable parts. Those are usually
done using some kind of META-INF/services in a plain java world, but this is
not always the best way to go in OSGi. I don't know if / where that applies
to ApacheDS. This can be deferred, as a simple OSGi integration can be made
to work without rewriting those bits for OSGi.
The last step is to actually use OSGi as your default container, which would
actually help finding problems in OSGi, but this it could be quite a
disruptive move for the users, because a lot of the configuration would have
to change. This is where Karaf actually comes into play and provides you a
ready to use container.
Ok, all this won't be obvious... We have to think about the consequences
on our code base. And as we are targetting a 2.0-RC1 release pretty
soon, I suggest we wait a bit before moving to OSGi so that the code
base stabilize. Then we can spend some time to OSGIfy the code, *before*
going to 2.0-RC1.
Actually, i've just seen that trunk includes an osgi module that seems to
build a big bundle containing lot (most ?) of the ApacheDS classes. That is
also one way of providing an OSGi integration point. Might not be the best,
but it allows users to actually deploy DS in an OSGi environment, although
not in a very modular way.
It was an early effort, not sure we want to resume it?
So there are different ways to go, I guess the one you want to take need to
be discussed.
Yop. One thing : I will go in Normandy end of next week (week-end at
Langrune s/mer), may be a good opportunity to discuss some technical
aspect or even to give it a try F2F on a branch on friday (I can be
there on friday morning instead of evening). Your call.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
