On Tue, Jun 8, 2010 at 18:07, Emmanuel Lecharny <[email protected]> wrote:
> 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? I guess no if we plan to go down a better way. Stefan say that there are some split packages. I think this issue need to be addressed asap. > > 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. Sure, that's a good idea. We can arrange that off-list. > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
