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) Darren On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam <t...@apache.org> 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 files > 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 BigRock.com >
