You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/03/05 05:42:40 UTC

[jira] Closed: (MODPYTHON-24) mod_python.publisher loading wrong module and giving no warning/error

     [ http://issues.apache.org/jira/browse/MODPYTHON-24?page=all ]
     
Graham Dumpleton closed MODPYTHON-24:
-------------------------------------


> mod_python.publisher loading wrong module and giving no warning/error
> ---------------------------------------------------------------------
>
>          Key: MODPYTHON-24
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-24
>      Project: mod_python
>         Type: Bug
>     Versions: 3.1.4
>     Reporter: Graham Dumpleton
>     Assignee: Nicolas Lehuen
>      Fix For: 3.2.7

>
> In publisher.py, modules are loaded using the code:
>     try:
>         module = apache.import_module(module_name,
>                                       autoreload=autoreload,
>                                       log=log,
>                                       path=[path])
>     except ImportError:               
>         et, ev, etb = sys.exc_info()
>         # try again, using default module, perhaps this is a
>         # /directory/function (as opposed to /directory/module/function)
>         func_path = module_name
>         module_name = "index"
>         try:
>             module = apache.import_module(module_name,
>                                           autoreload=autoreload,
>                                           log=log,
>                                           path=[path])
>         except ImportError:
>             # raise the original exception
>             raise et, ev, etb
> The intent here being that if it can't find /directory/<module>/<function> that
> it will instead look for /directory/index/<function>. Previous bug report noted
> that the new func_path should be combination of module_name and existing
> value of func_path, but there is another issue with this code.
> The problem is that the second import should really only be tried if the first module
> didn't in fact exist at all. The second import however will be attempted when any
> type of ImportError occurs. This could lead to a coding error in the first module not
> being detected because any such error is silently ignored.
> For example, image the first module was called "page.py" and contained:
>   import xxx
>   def index():
>     return "page/index"
> and the second module, ie., the fallback of "index.py" contained:
>   def page():
>     return "index/page"
> Note that the module "xxx" does not in fact exist.
> If one access the URL:
>   /page/index
> the "import xxx" fails and raises an ImportError.  This then causes "index.py"
> to be loaded instead and the result is:
>   "index/page"
> and not as desired:
>   "page/index".
> That there was any problem with importing "page.py" is not evident as any details
> of any error message are not logged.
> The only possible way around this and knowing that an error occured because of
> a module which wasn't there in the first place vs an error within the module being
> imported is perhaps that the result of:
>   f, p, d = imp.find_module(parts[i], path)
> in import_module() is checked somehow to see if a module could be found and if
> not raise a mod_python specific exception which could be detected by publisher
> as indicating a missing module which would then cause a fall through to the "index.py"
> default. Ie.,
>   try:
>     f, p, d = imp.find_module(parts[i], path)
>   excpt ImportError:
>     raise ModuleNotFound()
> Suggested solution not actually tried.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira