cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: [DISCUSS/PROPOSAL] Upgrading Driver Model
Date Thu, 22 Aug 2013 23:44:50 GMT
Spring is not meant to be used as a solution for run-time "plug-ins".
Darren is correct that Spring XML should be treated as code (ideal place
for it is the resource section inside the jar). Why we end up the way now
is mainly for practical reason. Since most of our current pluggable
features are not yet designed to be fully run-time loadable, most of them
have compile time linkage to other framework components that are solved at
loading time by Spring.

Only after we have cleaned up all these tightly coupled loading time
bindings, can we have a much simpler plugin configuration. And this
run-time loadable framework does not necessary to be based on any complex
ones (i.e., OSGi).


On 8/21/13 8:42 AM, "Darren Shepherd" <> wrote:

>I also agree with this.  Spring XML should always be treated as code not
>really configuration.  It's not good to have a sysadmin touch spring
>config and frankly it's just mean to force them to.
>I would ideally like to see that registering a module is as simple as
>putting a jar in a directory.  If its in the directory it gets loaded.
>Then additionally you should have a way such that you can explicitly tell
>it not to load modules based on some configuration.  That way, if for
>some reason moving the jar is not possible, you can still disallow it.
>So for example the directory based approach works well with rpm/deb's so
>"yum install mycoolplugin" will just place jar somewhere.  But say your
>troubleshooting or whatever, you don't really want to have to do "yum
>remove..." just to troubleshoot.  It would be nice to just edit some file
>and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam <> wrote:
>> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
>>> Leaky Abstraction:  Plugins are registered through a Spring
>>> configuration file.  In addition to being operator unfriendly (most
>>> sysadmins are not Spring experts nor do they want to be), we expose
>>> the core bootstrapping mechanism to operators.  Therefore, a
>>> misconfiguration could negatively impact the injection/configuration
>>> of internal management server components.  Essentially handing them
>>> a loaded shotgun pointed at our right foot.
>> This has been my pet-peeve too and I was told you can write properties
>> above the spring contexts to make it simpler for operators to look at.
>> Overall a great proposal and look forward to see more concrete steps
>> that follow on the implementation details.
>> -- 
>> Prasanna.,
>> ------------------------
>> Powered by

View raw message