Daan, I think I mentioned in my proposal to defer hot loading/unloading to a later release. It is a hard issue, and not required to address the current pain points.
Thanks, -John On Aug 25, 2013, at 7:43 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > 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 >>>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
