import_module() and multiple modules of same name.
--------------------------------------------------

Key: MODPYTHON-115
URL: http://issues.apache.org/jira/browse/MODPYTHON-115
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4, 3.2
Reporter: Graham Dumpleton


The "apache.import_module()" function is a thin wrapper over the standard Py
thon module importing system. This means that modules are still stored in "s
ys.modules". As modules in "sys.modules" are keyed by their module name, thi
s in turn means that there
can only be one active instance of a module for a specific name.

The "import_module()" function tries to work around this by checking the pat
h name of the location of a module against that being requested and if it is
 different will reload the correct module. This check of the path though onl
y occurs when the "path" ar
gument is actually supplied to the "import_module()" function. The "path" is
 only supplied in this way when mod_python.publisher makes use of the "impor
t_module()" function, it is not supplied when the "Python*Handler" directive
s are used because in that
circumstance a module may actually be a system module and supplying "path" w
ould prevent it from being found.

Even though mod_python.publisher supplies the "path" argument to the "import
_module()" function, the check of the path has bugs, with modules possibly b
ecoming inaccessible as documented in JIRA as MODPYTHON-9.

The check by mod_python of the path name to the actual code file for a modul
e to determine if it should be reloaded, can also cause a continual cycle of
 module reloading even though the modules on disk may not have changed. This
 will occur when successive
requests alternate between URLs related to the distinct modules having the s
ame name. This cyclic reloading is documented in JIRA as MODPYTHON-10.

That a module is reloaded into the same object space as the existing module 
when two modules of the same name are in different locations, can also cause
 namespace pollution and security issues if one location for the module was 
public and the other privat
e. This cross contamination of modules is as documented in JIRA as MODPYTHON
-11.

In respect of the "Python*Handler" directives where the "path" argument was 
never supplied to the "import_module()" function, the result would be that t
he first module loaded under the specified name would be used. Thus, any sub
sequent module of the same
name referred to by a "Python*Handler" directive found in a different direct
ory but within the same interpreter would in effect be ignored.

A caveat to this though is that such a "Python*Handler" directive would resu
lt in that handlers directory being inserted at the head of "sys.path". If t
he first instance of the module loaded under that name were at some point mo
dified, the module would be
automatically reloaded, but it would load the version from the different dir
ectory.

Now, although these problem as they relate to mod_python.publisher are addre
ssed in mod_python 3.2.6, the underlying problems in 'import_module()' are n
ot. As the bug reports as they relate to mod_python.publisher have been clos
ed off as resolved, am crea
ting this bug report so as to carry on a bug report for the underlying probl
em as it applies to "Python*Handler" directive and use of "import_module()" 
explicitly.

To illustrate the issue as it applies to "Python*Handler" directive, create 
two separate directories with a .htaccess file containing:

AddHandler mod_python .py
PythonHandler index
PythonDebug On

In the "index.py" file in each separate directory put:

import os
from mod_python import apache

def handler(req):
req.content_type = 'text/plain'
print >> req, os.getpid(), __file__
return apache.OK

Assuming these are accessed as:

/~grahamd/mod_python_9/subdir-1/index.py
/~grahamd/mod_python_9/subdir-2/index.py

access the first URL, and the result will be:

10665 /Users/grahamd/Sites/mod_python_9/subdir-1/index.py

now access the second URL and we get:

10665 /Users/grahamd/Sites/mod_python_9/subdir-1/index.py

Note this assumes the same child process got it, so fixing Apache to run one
 child process is required for this test.

As one can see, it doesn't actually use the 'subdir-2/index.py" module at al
l and still uses the "subdir-1/index.py' module.

If one modifies "subdir-1/index.py' so its timestamp is updated and load the
 second URL again, we get:

10665 /Users/grahamd/Sites/mod_python_9/subdir-2/index.py

This occurs because it detects the change in the first module loaded, but be
cause sys.path had the second handler directory at the head of sys.path now,
 when reloaded it picked up the latter.

These issues with same name module in multiple locations is listed as ISSUE 
14 in my list of module importer problems. See:

http://www.dscpl.com.au/articles/modpython-003.html

[ Post a follow-up to this message ]