Kelven, Please don't take my proposal as a criticism of the approach taken in 4.1. I think the current model is a big improvement over the previous approach. Given the time constraints and ambitions of that work, I think it was a solid, pragmatic first step. I believe we are at a point to assess our needs, and determine a good next step that (hopefully) further improves the model.
Thanks, -John On Aug 22, 2013, at 7:44 PM, Kelven Yang <kelven.y...@citrix.com> wrote: > 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 >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
