incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: [DISCUSS] OSGi framework for plugins and more?
Date Tue, 13 Nov 2012 21:05:48 GMT
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.mohammad@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.mohammad@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"
>><HTrippaers@schubergphilis.com>
>> wrote:
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Kelven Yang [mailto:kelven.yang@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.childers@sungard.com>
>> wrote:
>> > >
>> > > >On Mon, Nov 12, 2012 at 4:12 AM, Hugo Trippaers
>> > > ><HTrippaers@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


Mime
View raw message