incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Zhang <Frank.Zh...@citrix.com>
Subject RE: Proposal to use OSGi for component modularity
Date Wed, 30 May 2012 22:59:31 GMT
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.Zhang@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

Mime
View raw message