On Mon, Nov 12, 2012 at 4:12 AM, Hugo Trippaers <htrippa...@schubergphilis.com> wrote: > Hey all, > > With the recent discussions on refactoring CloudStack and the working going > into javelin I would like to discuss using OSGi. The background is that I > have been struggling with ideas on how to setup a plugin system for > CloudStack that would allow plugins to be separate entities which can be > release independently from CloudStack core. Mainly to deal with the current > non-asf components but for future expansion as well. > > While at ApacheConEU I had the chance to discuss these ideas with one of our > mentors after his talk about OSGi. I'm pretty charmed by OSGi and the options > it provides. It's a well thought out system that allow true modularity and > pluggability. With the amount of support in the java industry it's a standard > that feels very mature and a safe bet, one I would prefer to any homegrown > plugin system. It supports versioning of components, strict separation of > classes between components and all kind of funky features like hot-plugging > and hot-replace. Using OSGi would mean that people can supply bundles with > functionality which are maintained separately from the 'main code' without > having to worry about how to integrate it with the core. Just putting the > module in the right directory should be enough to get CloudStack to see and > use the bundle. Upgrades happen the same way, new version of an > authenticator, just replace the bundle and let the framework replace it with > having to shutdown the server at all. > > As we are discussing making CloudStack more modular, I would like to propose > to start using OSGi for this. It is a bit of a learning curve to start with, > but one we can get help with from our mentors. I'm already working on setting > up a proof of concept for a plugin system using OSGi together with a > colleague to show how it works, code is always better than words. > > So what are your thoughts? > > Cheers, > > Hugo >
I'm not familiar enough with OSGi to understand the tradeoffs of that vs other frameworks, but I'd suggest that Kelvin weigh in here. The work that he's doing on the Javelin branch is similar, and there might be an argument for Spring instead. Kelvin, I know you just responded on the other thread about the relative timing of a switch. Want to weigh in on the OSGi approach's technical merit vs. other options? -chip
