|
Huzaifa Tapal
huzaifa at hostway.com
Fri Apr 29 15:58:03 EDT 2005
I wanted to ask for a piece of advise. So the fix that I have
mentioned, I moved that fix (the method I replaced with the map(lambda)
solution you had with a minor fix) to another "SharedResources" module
that I import in my framework's handler. From within the handler and my
app, I am call that method passing in a path argument that it *fixes*
and returns back the results. Here is what the new method looks like:
def fix_paths( path ):
""" Convenience method for checking and
adding '/' to the end of paths for compatibility
with mod_python's import_module. """
_lock.acquire()
try:
if path and type(path) == type([]):
path = map(lambda entry : (entry!='' and entry[-1]!='/' and
entry+'/') or entry,path)
return path
finally:
_lock.release()
Should I have the thread-locking in place or can I get by without having
it in place? The reason I did add that was because the path value may
get changed, in the process, I thought of making this method thread-safe.
Also Nicolas, if you notice I added another check in your lambda
function to check if the entry is an empty string. If that wasn't there
then if an empty string path was passed in the list paths, the function
would break. Thought, i'd let you know if you were gonna add this
functionality into the import_module method for apache.py
Thanks
Hozi
Nicolas Lehuen wrote:
>Sorry, reposting to the whole list :
>
>Hi,
>
>The change I've made for MODPYTHON-9 affects only the publisher
>module. It solves the problem encountered when you had two pages, one
>at /index.py, and the other at /foobar/index.py.
>
>Huzaifa, what I don't understand here is whether moduleA has the same
>name as moduleB, and whether you are using mod_python.publisher or
>not.
>
>If you use the publisher, your problem has been solved in the latest
>development version, and the fix will be in the next release.
>
>Anyway, if we put aside the fix specific to the publisher, the problem
>you describe is real, and the workaround you provide is correct.
>
>It is so correct that the only way I see of fixing that is to
>integrate the workaround in the import_module function, that is to say
>to check whether each path component passed in the path list argument
>ends with a '/' (or '\'), and if not, add a '/' (or '\\'). This is
>done easily in the first line of the function :
>
>if path:
> path = map(lambda entry : (entry[-1]!='/' and entry+'/') or entry,path)
>
>However, there is no easy way of telling what directory separator
>should be used ; theoretically, os.sep gives us the correct directory
>separator, but even under Win32 Apache admins are advised to use "/"
>which is compatible (at the OS level). So, we might as well always use
>"/".
>
>What I fear is that adding all these checks to import_module will make
>it a little bit too slow, so what about adding a line or two in the
>documentation about the fact that all directories mentioned in the
>path argument should end with a '/' ?
>
>Regards,
>
>Nicolas
>
>On 4/29/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
>
>
>>Nicolas, does the change you have already made for MODPYTHON-9
>>also address this slightly different variation on the problem?
>>
>>Original report was based on same name module in parent and child
>>subdirectories, not sibling directories which share a common prefix
>>to the subdirectory name.
>>
>>Graham
>>
>>Huzaifa Tapal wrote ..
>>
>>
>>>For my fix, I patched this issue by passing the import_module function
>>>the path with "/" in the end. That way it distinguishes from
>>>/home/user/dir1 and /home/user/dir123
>>>
>>>hozi
>>>
>>>Graham Dumpleton wrote:
>>>
>>>
>>>
>>>>See:
>>>>
>>>> http://issues.apache.org/jira/browse/MODPYTHON-9
>>>> http://issues.apache.org/jira/browse/MODPYTHON-10
>>>> http://issues.apache.org/jira/browse/MODPYTHON-11
>>>>
>>>>There are various known issues with using same name module in different
>>>>directories.
>>>>
>>>>The first one has been addressed for next version of mod_python.
>>>>
>>>>Graham
>>>>
>>>>On 29/04/2005, at 8:22 AM, Huzaifa Tapal wrote:
>>>>
>>>>
>>>>
>>>>>I think there is a bug in apache.import_module. I am using
>>>>>apache.import_module passing in the path where I want the module
>>>>>imported from. I am seeing a very odd result as to sometimes, the
>>>>>module that is loaded is not the right one. Instead it loads a
>>>>>module that is of the same name but in a different directory. Here
>>>>>is what is happening:
>>>>>
>>>>>I have two modules of same name in 2 different directories as follows;
>>>>>
>>>>>/home/user/dir1/moduleA
>>>>>/home/user/dir123/moduleB
>>>>>
>>>>>Lets say I restart apache and load up moduleA. At that point there
>>>>>is an entry in sys.modules for moduleA. Lets say then, I load up
>>>>>moduleB, now the original entry for moduleA is overwritten by this
>>>>>new entry. Now when I go back to load moduleA, I get back moduleB
>>>>>results. Here is why:
>>>>>
>>>>>In apache.import_module if I pass in the path to load moduleA from
>>>>>'/home/user/dir1' and the last module was in '/home/user/dir123' then
>>>>>the check in import_module to make sure both modules aren't the same
>>>>>fails since it does a "file.startswith()" check on the path. Since
>>>>>the path moduleA is in the path to moduleB, it loads the wrong module.
>>>>>
>>>>>I see that somebody else had complained about this problem in
>>>>>mod_python 1.3.1 but it still has not been patched.
>>>>>
>>>>>Any ideas?
>>>>>
>>>>>Hozi
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Mod_python mailing list
>>>>>Mod_python at modpython.org
>>>>>http://mailman.modpython.org/mailman/listinfo/mod_python
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>Mod_python mailing list
>>Mod_python at modpython.org
>>http://mailman.modpython.org/mailman/listinfo/mod_python
>>
>>
>>
>
>_______________________________________________
>Mod_python mailing list
>Mod_python at modpython.org
>http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20050429/979e07ea/attachment.html
|