WSGIImportScript only allowed at global server configuartion.

[GoogleCodeExporter]

WSGIImportScript at present only seems to be allowed at global server 
configuration.

This is a bit odd, as one can refer to process-group which is defined within 
VirtualHost scope.

Should it be allowed in VirtualHost as well?

In VirtualHost scope it may still need to be necessary to allow 
process-group=%{GLOBAL} but if not that, should 
only be allowed to reference process-group defined in same VirtualHost or at 
global server config level. Ie., 
should not be allowed to reference process-group defined in another VirtualHost.

To have this checking though would require configuration directives to be 
ordered properly. That is, 
WSGIImportScript would have to come after WSGIDaemonProcess directive it is 
referring to.

Is this all worth the trouble since in version 3.0 it will be possible to have 
process-group and application-group 
associated with WSGIScriptAlias and trigger preloading with that.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 21 Sep 2008 at 9:39

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 20 Dec 2008 at 11:10

• Changed state: Started
• Added labels: Milestone-Release3.0

[GoogleCodeExporter]

Add in revision 1136 of subversion trunk for 3.0.

Note that an ordering requirement is now imposed. That is, WSGIDaemonProcess 
directive must appear before 
the WSGIImportScript or WSGIScriptAlias directive that references it. Further 
can only reference daemon 
process group in same VirtualHost or one at global server scope.

It is now not possible from global server scope to reference daemon process 
group defined in a VirtualHost. 
As this scenario was possible with mod_wsgi 2.X and WSGIImportScript was only 
able to be at global server in 
that version, likely that configuration files will need to change. The only 
configuration that would be 
compatible across both versions would be to have WSGIDaemonProcess and 
WSGIImportScript both at global 
server scope.

Original comment by Graham.Dumpleton@gmail.com on 22 Dec 2008 at 10:01

[GoogleCodeExporter]

Version 3.0 of mod_wsgi now released with this change.

Now wait for screams from people who had WSGIImportScript listed before 
WSGIDaemonProcess it related to.

Original comment by Graham.Dumpleton@gmail.com on 22 Nov 2009 at 2:56

• Changed state: Fixed

[GoogleCodeExporter]

I tried to migrate from mod_python to mod_wsgi 3.1 (to run Trac) and I 
experienced 
quite a few problems that I didn't find documented. 

On my server I run 2 Trac instances, potentially with different Trac version 
(this 
was not working properly with mod_python). My configuration involves importing 
a 
script to initialize the Python path appropriate for the Trac instance.

I had no problem as long as I was using mod_wsgi in embedded mode. As soon as I 
switched to daemon mode, the initialization script was no longer imported. I 
realized this was caused by mod_python still loaded and configured in the same 
web 
server. I have not found any mention in the documentation that mod_wsgi daemon 
mode 
was incompatible with mod_python, at least that the initialization script was 
not 
supported in this context. Not sure if this is a bug or a feature. I disabled 
mod_python and now everything is fine.

Michel

Original comment by mijou...@gmail.com on 9 Dec 2009 at 5:34

[GoogleCodeExporter]

Daemon mode of mod_wsgi should not be incompatible with mod_python.

The documentation, in an obscure location, does say:

"""If mod_python needs to be available at the same time, it is recommended that 
mod_python 3.3.1 be used. If 
mod_python is not actually required it should not be loaded at all, as by 
loading it, it actually causes some 
features of mod_wsgi not to work, with equivalent configuration having to be 
done through mod_python with 
some loss of functionality as a result."""

Otherwise do acknowledge that what functionality is lost and what some of the 
problems that can arise are not 
documented.

Since you say you had multiple problems, please post to the mod_wsgi mailing 
list with details what all of them 
were. Please don't post followup comments to a partially related and closed 
issue on the issue tracker. Unless 
you explain what the issues were, then if there are problems and it wasn't just 
a configuration problem, then 
they will never be fixed or documented as necessary.

Original comment by Graham.Dumpleton@gmail.com on 9 Dec 2009 at 10:40