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). Kelven On 8/21/13 8:42 AM, "Darren Shepherd" <darren.s.sheph...@gmail.com> 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) > >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 >>
