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.sheph...@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.hoogl...@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.sheph...@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 > >
