[Grok-dev] multiple grok wsgi applications possible?

[Chris McDonough]

Chris McDonough wrote:
> Brandon Craig Rhodes wrote:
>> Chris McDonough <chrism at plope.com> writes:
>>
>>> Brandon Craig Rhodes wrote:
>>>
>>>> I'd assumed you were just overwriting
>>>> `zope.component.globalregistry.globalSiteManager`...
>>> 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.

It's an excellent idea, but it's also kinda hard.

It means that we'd need to supplant the value of
zope.component.globalregistry.globalRegistry with something that was thread
local.  Can you *do* this for a module-scope global?  I don't think you can?

Assuming you can't, it means that you'd need to create an implementation of
_IGlobalSiteManager that multiplexed for a number of registries and you'd nee to
create an instance of that as the value of
zope.component.globalregistry.globalRegistry.

It might be more efficient to just monkey-patch the original definition of
getGlobalSiteManager as well?

- C