On 11/12/12 1:34 PM, "Chip Childers" <chip.child...@sungard.com> wrote:
>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? It will be nice to see the OSGi technical merit vs. other option in details. Laying out these basic but fundamental frames may not benefit a lot in the short term, but we may get fully paid in long term. Spring can only give us solution on compile-time/load-time component integration, it focuses more on internal component wiring, OSGi seems to focus more at runtime, I think these two may be complementary to each other. > >-chip
