[Grok-dev] multiple grok wsgi applications possible?
chrism at plope.com
Wed Dec 17 16:22:40 EST 2008
Brandon Craig Rhodes wrote:
> Chris McDonough <chrism at plope.com> writes:
>> Brandon Craig Rhodes wrote:
>>> I'd assumed you were just overwriting
>> Yes, during initial registry population (e.g. xmlconfig.include(...))
>> this is exactly what we do.
> I'm not convinced; it looks like your code (thanks for providing the
> link a moment ago! it's good reading...) does not actually touch the
> global variable that I'm citing. Instead, it just touches the copy of a
> function at `zope.component.getGlobalSiteManager`.
> To clarify, there are three things here in play:
> `zope.component.getGlobalSiteManager` - An ``import`` into the
> `__init__.py` of `zope.component` that provides an easy,
> fewer-character location from which to import the global site
> manager function.
> `zope.component.globalregistry.getGlobalSiteManager` - The actual
> location at which the global site manager function lives. Since you
> fail to overwrite this location, there might be parts of Zope that
> import this real one instead of the `__init__.py` copy.
Indeed, you're right. I'm fairly confident that the subset of Zope components
that BFG depend upon just don't do this. At least if there are any, I haven't
found them yet. (FTR, BFG doesn't advertise itself as a system you can plug
arbitrary ZCA-based Zope code into, so if you tried a package that did do this,
and it broke, you'd get to keep both pieces.)
> `zope.component.globalregistry.globalSiteManager` - The global variable
> in the `globalregistry` module which `getGlobalSiteManager()` reads
> in order to find the global site manager. My proposal was that you
> could also overwrite this variable with a thread-local value holder
> that you write to before handing control over to the Zope publisher
> at the bottom of the WSGI stack, and then you'd have captured and
> redefined the idea of the "global registry" regardless of how code
> decided that they should get at it (whether through the
> `__init__.py` copy of the function, or the deeper real copy of the
> function itself, or through looking for the global variable - which,
> after all, is not preceded with an underscore, so a programmer could
> legitimately think he was allowed to look at and use its value...)
That's an excellent idea.
More information about the Grok-dev