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] Modularize Spring
Date Wed, 18 Sep 2013 18:22:34 GMT
What's the point in using separate spring context per plugin?
Separate class loader is the thing I hate most in OSGI, I am afraid we are on the same way.
Frankly speaking, I never see benefits of this *separate* model,  our project(or most projects)
is not like Chrome which has to create sandbox for extensions 
in order to avoid bad plugin screws up the whole browser(however, I still see bad plugins
screw up my Chrome well).
Projects like CloudStack using plugin to decouple architecture should not introduce many isolations
to plugin writer, the point preventing wrong use of some components
is not making much sense to me. If a plugin not following guide(if we have it) we should kick
it out, instead of making obstacles for 99% good people. 



> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
> Sent: Wednesday, September 18, 2013 10:33 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Modularize Spring
> 
> Right, component isn't a thing.  I probably shouldn't use that term.  I want to
> standarize on the naming convention of plugin, module, and extension.  It is
> explained a bit on the wiki [1] but I'll try to do a little better job here.  So a
> plugin is basically a jar.  A jar contains multiple modules.  A modules ends up
> being a spring application context that composes multiple configuration files.
> Modules are assembled into a hierarchy at runtime.  Extensions are
> implementations of interfaces that exist in a module.  A maven project
> produces a jar, so a plugin ends up being a maven project also.
> 
> So currently today we don't have a strong definition of Plugin and I hope to
> address that.
> 
> Darren
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-
> ins%2C+Modules%2C+and+Extensions
> 
> 
> On Wed, Sep 18, 2013 at 4:25 AM, Daan Hoogland
> <daan.hoogland@gmail.com>wrote:
> 
> > sounds great Darren,
> >
> > By component, you mean maven project or some larger chunk like
> > distribution package? (did i miss this definition somewhere or do we
> > define the components now?)
> >
> > regards,
> > Daan
> >
> > On Wed, Sep 18, 2013 at 12:10 AM, Darren Shepherd
> > <darren.s.shepherd@gmail.com> wrote:
> > > Currently ACS code is fairly modular in that you can add plug-ins to
> > > ACS
> > to
> > > extend most functionality.  Unfortunately ACS is not packaged in a
> > modular
> > > way.  It is still delivered essentially as one large unit.  There
> > > are
> > many
> > > reason for this but one large barrier to modularizing ACS is that
> > > the Spring configuration is managed as one large unit.
> > >
> > > I propose that we break apart the Spring XML configuration such that
> > > each component contributes its own configuration.  Additionally each
> > > component will be loaded into its own Spring ApplicationContext such
> > > that its beans will not conflict with the wiring of other beans in
> > > ACS.  This change
> > will
> > > lay the foundation for a richer plugin model and additionally a more
> > > distributed architecture.
> > >
> > > The technical details for this proposal can be found on the wiki [1].
> > >
> > > Darren
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Spri
> > ng
> >

Mime
View raw message