Another problem I want to raise here is the class loader issue. There are bunch of places in CloudStack using Class.forName(), I am sure ClassNotFoundException would then be our best friend.
> -----Original Message----- > From: Frank Zhang [mailto:frank.zh...@citrix.com] > Sent: Wednesday, May 30, 2012 11:32 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: Proposal to use OSGi for component modularity > > 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
