It seems I am the only one not sharing your reservations regarding OSGi, so let's go for it, John.
I would personally try to not bother with the hot-loading and -unloading of drivers and create a install and a drivers directory for all running processes, where these will be checked upon starting to update or install any new stuff. If a real life-cycle management is needed on run-time I would once again urge to go with OSGi. I would love to help on this not withstanding any objection I have on the way to go. It seems like fun to implement:) Daan On Fri, Aug 23, 2013 at 1:44 AM, 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 >>> >
