Hi Kelven, As Spring/Spring DM can be used on Apache Karaf (multi-container OSGI runtime), that should not be a problem to use what you have done on Karaf. Maybe we can talk about that next on IRC channel (@ch007M)
Regards, On Tue, Nov 13, 2012 at 10:05 PM, Kelven Yang <kelven.y...@citrix.com>wrote: > The refactoring work that I did on Spring exploration is an incremental > approach trying to improve and encourage modularity of CloudStack, I hope > it will help CloudStack in the future to add OSGi in the future. > > As we have a huge amount of legacy code base, it will be less risky to do > incremental changes, and Spring effort here is the closest match of what > we have in our existing code base. What we are trying to achieve is to > first enable internal java modules to be more component-ized, our > customized component framework actually provides 99% things we need, > instead of us to fix the missing 1%, I feel that it might be worth to just > switch to a more standard framework with a minimal effort. It is that > simple :-). It is also easier to get things moving, in the end, if we > have a well component-ized system internally, it will be easier to adopt > any "the best" option like OSGi > > Kelven > > > On 11/13/12 8:09 AM, "Mohammad Nour El-Din" <nour.moham...@gmail.com> > wrote: > > >Hi > > > >Had typos in this message the correct one is here: > > > >hi > > > > we already had this discussion before earlier when ACS was just donated > >to ASF. > > > >I am not an OSGi expert at all :), but I would like to know what is the > >problem that needs to be solved rather than discussing or jumping into the > >solution first > > > >OSGi has a lot of magnificent features idd but do we really need them all, > >and also what does all these features add to us in the context of the > >context of the cloud. to be honest I don't have a definite answer and > >that's why I would suggest to list what we need to achieve regarding that > >part and look into the alternatives and choose what is best for us, OSGi > >is > >one option for sure > > > >Feedback/input ? > >On Tue, Nov 13, 2012 at 8:30 AM, Mohammad Nour El-Din < > >nour.moham...@gmail.com> wrote: > > > >> hi > >> > >> we already had this discussion before earlier when ACS was just > >>donated > >> to ASF. > >> > >> I am not an OSGi expert at all :), but I would like to know what is the > >> problem that needs to be solved rather than discussing the solution > >>first > >> > >> OSGi has a lot of magnificent features idd but do we really need them > >>all, > >> and also what does all these features add to us in the context of the > >> context of the cloud. to be honest I don have a definite answer and > >>that's > >> why I would suggest to list what we need to achieve regarding that part > >>and > >> look into the alternatives and choose what is best for us, OSGi is one > >>of > >> them for sure > >> > >> Feedback/input ? > >> > >> Sent from my Samsung Galaxy S3 > >> Apologies for any typos > >> > >> On Nov 13, 2012 7:56 AM, "Hugo Trippaers" > >><htrippa...@schubergphilis.com> > >> wrote: > >> > > >> > > >> > > >> > > -----Original Message----- > >> > > From: Kelven Yang [mailto:kelven.y...@citrix.com] > >> > > Sent: Monday, November 12, 2012 11:31 PM > >> > > To: cloudstack-dev@incubator.apache.org > >> > > Subject: Re: [DISCUSS] OSGi framework for plugins and more? > >> > > > >> > > > >> > > > >> > > 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. > >> > > >> > To a certain extent these technologies can be used together, but not > >>in > >> this way it seems. OSGi is a framework that focusses on separation of > >>code > >> in various modules in such a way that other modules can not see and work > >> with the classes in other modules excluding via well defined services. > >>This > >> is a fundamental choice that touches the core of how CloudStack would be > >> put together. Instead of a single codebase (or at runtime a single > >> classloader) where modules would be loaded via (for example) the spring > >> framework based on an xml definition, the core would be an empty > >>framework > >> and modules work be plugged in and provide a certain service. This can > >>be > >> done at load time or runtime, that up to the implementers. For example > >>say > >> the core module would need a vm provisioned it would ask the service > >> registry if there was a service able to provide this functionality, if > >> there was that service would be asked to perform that task. Here is a > >>short > >> post that describes the context far better than I can: > >> http://elron.us/?p=95 .The real benefits are in also in the modularity, > >> because the framework is very strict on what bundles/interfaces are > >>exposed > >> and required, using the proper interfaces and limiting yourself to > >>exposed > >> interfaces is enforced by the framework. > >> > > >> > Hugo > >> > > > >> > > > >> > > > > >> > > >-chip > >> > > >> > >> > > > > > >-- > >Thanks > >- Mohammad Nour > >---- > >"Life is like riding a bicycle. To keep your balance you must keep moving" > >- Albert Einstein > > -- Charles Moulliard Apache Committer / Sr. Enterprise Architect (RedHat) Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
