I have some different thoughts here > On Tuesday, May 29, 2012 at 10:29 PM, Alex Huang wrote: > > > CloudStack is built as a product with modularity enforced by interfaces. It > had its own component management via ComponentLocator. While that > framework made it easy for a small group of developers to work together, it > has outlived its usefulness. Now that we are expecting more developers to > join Apache CloudStack, we're looking for the next component framework to > scale code development. This framework needs to manage the following: > > - life cycles of the components > > - enforce boundaries between components > > - easily allow components to be upgraded/downgraded > > - database upgrades for the component > > > > The most successful of such an application is Eclipse, which uses framework > defined by OSGi. We're planning to use that for our component framework. > > > > I like to gather opinions about > > > > 1. Whether to use OSGi or there should be other frameworks to consider? > Personally, I would absolutely love to see osgi explored. We have been using > osgi with great success for ServiceMix for several years and have learned > volumes about the ins and outs. For a controlled server environment like > Cloudstack, I think it would be ideal. There are some learning curves, and > some extra work involved, but the rewards are plenty.
First I don't think CloudStack needs to update or remove bundle on the fly. This feature looks ideal, but considering a cluster management nodes, for example four running mgmt nodes, how to propagate bundle upgrade on one mgmt node to others? And how to guarantee all bundles get working only after all mgmt nodes gets upgraded? I don't know if OSGI is capable of this problem. To me runtime upgrade introduces much complexity, at least to CloudStack. Second I think the bundle boundary of OSGI is too tiny. I may be wrong here, as I am not OSGI expert. I was thinking it is a good idea to treat every interface as a service? For example, logging, I hope the logging package used by every bundles is linked in it, instead of packaging it as a logging bundle. CloudStack should focus on its own bundle, like network bundle, storage bundle. As CloudStack is a integration project it uses a lot of thirdparty libraries, spending too much time in repackaging libraries I thought should be my linkage dependency to OSGI service distracts us from main business. I know there are some projects repackaging common java libraries, I just simply suspect if it is the best practice for plugin system. And about extender. Now CloudStack itself is responsible for loading all components and starting them. As I know in OSGI this is work of extender, does it mean we have to write our extender? I know we can use dependency in MANIFEST file, but I don't know how it guarantees loading order. To me using scattering files to describe inter-dependency to guarantee loading order makes people hard to know the exact loading sequence. And what I dislike MANIFEST file most is you have to recompile every time you change it. > > > 2. If OSGi, whether to use Equinox or Apache Felix? > > > > > > I am biased having been involved with Felix and Karaf for many years, but I > would encourage you to look at Karaf and Felix as a base for the container > (eplained more below). You will get assistance from within the Apache > community by way of Karaf, Felix, and several other projects that also use > these frameworks (Geronimo, Camel, Sling, probably many others now) and > those projects will mutually benefit from input and contributions via > Cloudstack. Does Apache have any OSGI runtime to ease developing? I am not sure if I use correct notion. I mean something like Eclipse Virgo that builds on OSGI engine. > > > 3. The tool to help integrate the OSGi framework into tomcat (Sling?) > > > > > > I recommend considering an inversion of this and instead look at hosting your > web server inside the osgi container (or something along these lines). In > this > way, agents and servers could be modularized similarly. You can certainly use > an osgi framework to provide modularity embedded in a standalone java app > or Tomcat, but I think you will find a lot of rewards in bootstrapping your > jvm > with osgi as a container (see Karaf, ServiceMix et al). I agree. Making CloudStack standalone allows us to integrate with other web server like Jetty. However, I know Eclipse Virgo builds a Tomcat in its OSGI runtime. However it's based on Spring that doesn't fit in current CloudStack. > > > 4. Anything we can use to upgrade/downgrade database versions? > > > > > > Not exactly sure what you are asking here, but if you mean DB migration, I > can;t think of anything osgi related that applies here so I think you will > have > to roll your own solution. > > > > > Please let me know your feedbacks. > > > > --Alex
