That's what my thought too
> -----Original Message----- > From: nour.moham...@gmail.com [mailto:nour.moham...@gmail.com] > On Behalf Of Mohammad Nour El-Din > Sent: Thursday, May 31, 2012 11:36 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: Proposal to use OSGi for component modularity > > Hi... > > On Thu, May 31, 2012 at 8:11 PM, Frank Zhang <frank.zh...@citrix.com> > wrote: > > > Thanks for explanation. These concerns may be too technical not > > relating much to architecture requirement that Alex mentioned. > > I raised them here because I could not figure out them in my one week > > OSGI journey. I admit that I might not spend enough time, but I feel > > one week is enough to get an idea of if the technology suits my > > requirement. I looked into Felix and Spring DM (which turns out to be > > Eclipse Virgo), Felix is quick to ramp up while Spring DM has better > > document. I know the best way to understand OSGI is reading its spec, > > but the 1500 pages specification is daunting. > > > > "Do you need modularity in your application?" I believe everybody will > > answer yes. "Do you need OSGI?" I think the answer is "depends". > > The requirement is quite simple 1. No runtime update 2. Version > > control is not urgent. Then I am thinking why I have to overcome > > steep learning curve for my simple requirement, there are lots of ways to > go. > > > > And achieving modularity does not relate much to using whatever tool > > or framework, as long as the application itself is designed in modularity > > way. > > For instance, to join OSGI family, properly organizing MANIFEST.MF and > > recompiling would be good enough. > > > > I am the last one to claim knowledge about OSGi, so pardon me if I look like > bluffing here :). > > But from what you said Frank, and what others proposed, I think you don't > need that kind of modularity facilitated by OSGi or like technologies, I > believe > all what we need then is: > > 1- Good design > 2- Good documentation about adding new modules/components > 3- Managing modules/components dependencies using maven for example > 4- Good code organization to reflect this modularity on code level in the repo > > Which this something we already do at Hippo, my employer, so in our case > each component is managed in its own SVN repo and we control which > versions of which components to package using release poms > > And with some provisioning like ACE can deliver to us we can automate that, > or even add drivers or provisioners, IDK what they are called, to ACE to > facilitate deploying diff modules based on that structure > > Or you can use OSGi as a base technology but AFAIK you don't need to use > everything it provides, which has the advantage that in the future we can > leverage these features if required > > > > > > > -----Original Message----- > > > From: Chris Custine [mailto:chris.cust...@gmail.com] > > > Sent: Wednesday, May 30, 2012 11:17 PM > > > To: cloudstack-dev@incubator.apache.org > > > Subject: Re: Proposal to use OSGi for component modularity > > > > > > On Wednesday, May 30, 2012 at 12:32 PM, Frank Zhang wrote: > > > > 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. > > > > > > > > > > > > > > Many ways to solve these issues if needed, but if you don't envision > > applying > > > runtime updates why be concerned about it? In either case, this > > > type of thing is addressed in the osgi spec, specifically parts > > > regarding service references, bundle lifecycle, and maybe startlevel. > > > > > > > > > > > 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. > > > > > > > > > > > > > > As time goes on, more and more projects are packaging jar files as > > > osgi bundles anyway (things are much better than they were 3 years ago). > > > However, there are quite a few resources for libraries that are not > > natively > > > packaged as osgi such as the servicemix bundle packages > > > (http://repo1.maven.org/maven2/org/apache/servicemix/bundles/) and > > > the Springsource enterprise bundle repository > > > (http://ebr.springsource.com/repository/app/), if all else fails, > > > there > > are > > > some fairly consistent methods for converting jars to bundles using > > maven. > > > > > > > > > > > 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. > > > > > > > > > > > > > > If I understand your concerns correctly, osgi exists as a solution > > > to > > these > > > problems, not to create them. I think that is why Alex raised the > > possibility of > > > using osgi in place of a project specific component model, to lower > > > the > > bar > > > for those wishing to contribute and to expand the community to the > > > many projects (both inside and outside Apache) using osgi as a > > > standard component model. I'm not sure it is worth diving into each > > > one of your technical issues individually, but I will be happy to do > > > so if it adds > > to the > > > discussion. Instead, I recommend looking at some of the projects I > > > mentioned previously for some great examples of osgi adding value > > > and solving complex issues. Osgi gives you a standard component > > > model and related services that are influenced by a diverse range of > > > requirements, > > how > > > and the extent to which you make use of it to assemble your systems > > > is completely up to you. > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Apache Karaf is a convenient packaging of value added bundles, > > > services, > > etc > > > that sits on top of Apache Felix (OSGi framework implementation) or > > Equinox. > > > I think Karaf is what you are looking for. > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > In Karaf, you can install the Jetty bundle (it is a native osgi > > > bundle) > > and deploy > > > war files that have access to osgi services and bundles. Karaf also > > includes > > > spring dm support (spring osgi extensions) as well as the osgi > > > blueprint > > spec, > > > which is a spec for xml based dependency injection specific to osgi. > > The point > > > of all of this is that you can have all of these coexist at the same > > time because > > > they are abstracted by the osgi component model. > > > > > > The main point I want to make is that the issues you raise here are > > > implementation details that will affect you no matter what component > > > model you choose. Your choice of component model should be based on > > > your current and future needs. Alex has stated the requirements in > > > the initial email and there are many of us working on other Apache > > > projects > > with > > > the same needs, also using osgi. As Alex mentioned in his email, > > adopting a > > > standard component model such as osgi will help you scale project > > > development, as well as the community. > > > > > > > > > > > > > > > 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 > > > > > > > -- > > -- > Thanks > - Mohammad Nour > ---- > "Life is like riding a bicycle. To keep your balance you must keep moving" > - Albert Einstein
