[Grok-dev] multiple grok wsgi applications possible?

[Chris McDonough]

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.

- C