[jira] Resolved: (MODPYTHON-155) req.add_handler() and inheritance of directory to be searched for module
[ http://issues.apache.org/jira/browse/MODPYTHON-155?page=all ]
Graham Dumpleton resolved MODPYTHON-155.
Fix Version/s: 3.3
Resolution: Fixed
To fix this, handler list now contains reference back to parent handler that
registered it dynamically. This is available as req.hlist.parent. Note that if
for some reason a dynamically added handler was in turn added by a dynamically
added handler, the immediate parent directory can be None. Thus need to keep
tracking back through parents until non None directory found or top handler
found. The directory can even then still be None if for example it was invoked
out of a Location directive.
A similar list back to parent handlers was also needed for filters which were
dynamically registered. This is available using filter.parent.
The new module importer has been updated to use these parent lists and thus now
possible to say:
from mod_python import apache
def uppercase(filter):
s = filter.read()
while s:
filter.write(s.upper())
s = filter.read()
if s is None:
filter.close()
def handler(req):
req.add_output_filter(UPPERCASE)
req.content_type = 'text/plain'
req.write('handler')
return apache.OK
def fixuphandler(req):
req.handler = 'mod_python'
req.register_output_filter(UPPERCASE, handlers::uppercase)
req.add_handler('PythonHandler', handlers::handler)
return apache.OK
and it will work correctly as it would have with old module importer.
req.add_handler() and inheritance of directory to be searched for module
Key: MODPYTHON-155
URL: http://issues.apache.org/jira/browse/MODPYTHON-155
Project: mod_python
Issue Type: Sub-task
Components: importer
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Fix For: 3.3
The documentation for req.add_handler() says:
Optional dir is a string containing the name of the directory to be added
to the pythonpath. If no directory is specified, then, if there is already a
handler of the same type specified, its directory is inherited, otherwise the
directory of the presently executing handler is used. I there is a PythonPath
directive in effect, then sys.path will be set exactly according to it (no
directories added, the dir argument is ignored).
This comment about the directory being inherited from the prior or currently
executing handler is actually bogus as the code does not do anything specific
at all to try and implement such behaviour. If it works this way at all it is
partly by luck as what will actually dictate where the module specified to
the req.add_handler() method is found is the current order of directories
specified in sys.path. Since additional directories added into sys.path by
the old importer can be performed in effectively random order, behaviour
could actually be quite random if the same module name were used in multiple
directories.
Because the new importer doesn't add directories into sys.path for
Python*Handler directives, a problem will currently arise if no directory is
supplied to req.add_handler(). Specifically, a module may not be able to be
found. This is because it can no longer fall back on to fact that with old
module importer, the directory corresponding to the Python*Handler directive
would be listed in sys.path somewhere.
Thus, the documented behaviour for req.add_handler() when the directory
hasn't been set needs to actually be implemented as described with an
appropriate directory being calculated at the time that req.add_handler() is
called with that directory being recorded as needing to be searched for the
module. In changing the code though, if old and new importers are going to be
supported during a transition phase, it must detect when the new module
importer is being used and only do this when it is, as otherwise it will
screw up how modules are found for the old importer.
--
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
[jira] Resolved: (MODPYTHON-164) Allow req.add_handler()/req.register_*_filter() to take module/function for handler.
[ http://issues.apache.org/jira/browse/MODPYTHON-164?page=all ] Graham Dumpleton resolved MODPYTHON-164. Fix Version/s: 3.3 Resolution: Fixed Allow req.add_handler()/req.register_*_filter() to take module/function for handler. Key: MODPYTHON-164 URL: http://issues.apache.org/jira/browse/MODPYTHON-164 Project: mod_python Issue Type: New Feature Components: core Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Currently, the: req.add_handler(phase, handler, dir) req.register_input_filter(filter_name, filter, dir) req.register_output_filter(filter_name, filter, dir) functions require the handler/filter to be a string. This string identifies the module that should be imported and which contains the necessary function, plus optionally, an alternate named function to the default for the phase or filter type. For example: req.add_handler(PythonHandler, mymodule::myhandler) It would be simpler if the handler/filter argument could be overloaded and instead supplied an actual module reference or callable object reference. For example: import mymodule def myhandler(req): ... def fixuphandler(req): req.add_handler(PythonHandler, mymodule) req.add_handler(PythonHandler, mymodule.myhandler) req.add_handler(PythonHandler, myhandler) return apache.OK This would be easier than having to construct a string module/function reference when you have direct access to the handler function. In the main the dir argument would be irrelevant. The only circumstance where it would matter is where PythonInterpPerDirective was used as it could be used to control the interpreter the code executed within. If not supplied, it could be argued that the directory where the supplied module/function is defined in should be used as dir. -- 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
[jira] Work started: (MODPYTHON-63) Handle wildcard in Directory to sys.path transfer
[ http://issues.apache.org/jira/browse/MODPYTHON-63?page=all ] Work on MODPYTHON-63 started by Graham Dumpleton. Handle wildcard in Directory to sys.path transfer - Key: MODPYTHON-63 URL: http://issues.apache.org/jira/browse/MODPYTHON-63 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.1.3 Environment: gentoo Linux 2.4.20-gentoo-r8 apache-2.0.54-r8 mod_python-3.1.3-r1 Reporter: Kevin Quick Assigned To: Graham Dumpleton Priority: Minor Below is a patch that does two things: 1) On module import failures, logfile contains additional information showing system paths as well as module name. 2) Support of Python*Handler found in a wildcard-based directory. For example, IfModule mod_python.c Directory /home/*/public_html/python AddHandler mod_python .py PythonHandler helloworld PythonDebug on /Directory /IfModule which mirrors a corresponding perl setting and would allow the user to place a mod_python handler in their $HOME/public_html/python directory. In the current code, the wildcard is not translated, the sys.path update will be invalid, and the user's module will not be accessible. The attached patch provides a fix for this. N.B. There are obvious security issues in using this type of configuration, but this is very useful for dev environments, and security would implemented via explicit alternatives anyhow. Index: apache.py === RCS file: /home/cvspublic/httpd-python/lib/python/mod_python/apache.py,v retrieving revision 1.83 diff -r1.83 apache.py 33a34,40 def add_handler_path(hpath): import glob if hpath: for D in glob.glob(hpath): if os.path.isdir(D) and D not in sys.path: sys.path.insert(0, D) 170,171c177 if filter.dir and (filter.dir not in sys.path): sys.path[:0] = [filter.dir] --- add_handler_path(filter.dir) 280,282c286 dir = hlist.directory if dir and (dir not in sys.path): sys.path[:0] = [dir] --- add_handler_path(hlist.directory) 454c458,462 f, p, d = imp.find_module(parts[i], path) --- try: f, p, d = imp.find_module(parts[i], path) except: _apache.log_error(mod_python: import error for module %s with path: %s and sys.path: %s%(parts[i],path,sys.path)) raise -- 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
mod_python 3.2.10 binaries for Win32
Hi,Here are the Win32 binaries for mod_python 3.2.10 :http://nicolas.lehuen.com/download/mod_python/There is one version for Python 2.3 + Apache 2.0, a version for Python 2.4 + Apache 2.0 and a version for Python 2.4 + Apache 2.2.All three version have passed the unit tests, so we can release them as soon as 3.2.10 is officially released.Regards, Nicolas
[jira] Reopened: (MODPYTHON-155) req.add_handler() and inheritance of directory to be searched for module
[ http://issues.apache.org/jira/browse/MODPYTHON-155?page=all ] Graham Dumpleton reopened MODPYTHON-155: Marked this resolved too soon. The code works fine, but looks like it could be memory inefficient due to the MpHList_FromHLEntry() function creating a new Apache memory pool and then also copying the underlying handler list when creating the handler list entry wrapper object. A new one of these handler list entry wrapper objects is going to be created each time parent() is called. Thus sub optimal at present. req.add_handler() and inheritance of directory to be searched for module Key: MODPYTHON-155 URL: http://issues.apache.org/jira/browse/MODPYTHON-155 Project: mod_python Issue Type: Sub-task Components: importer Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 The documentation for req.add_handler() says: Optional dir is a string containing the name of the directory to be added to the pythonpath. If no directory is specified, then, if there is already a handler of the same type specified, its directory is inherited, otherwise the directory of the presently executing handler is used. I there is a PythonPath directive in effect, then sys.path will be set exactly according to it (no directories added, the dir argument is ignored). This comment about the directory being inherited from the prior or currently executing handler is actually bogus as the code does not do anything specific at all to try and implement such behaviour. If it works this way at all it is partly by luck as what will actually dictate where the module specified to the req.add_handler() method is found is the current order of directories specified in sys.path. Since additional directories added into sys.path by the old importer can be performed in effectively random order, behaviour could actually be quite random if the same module name were used in multiple directories. Because the new importer doesn't add directories into sys.path for Python*Handler directives, a problem will currently arise if no directory is supplied to req.add_handler(). Specifically, a module may not be able to be found. This is because it can no longer fall back on to fact that with old module importer, the directory corresponding to the Python*Handler directive would be listed in sys.path somewhere. Thus, the documented behaviour for req.add_handler() when the directory hasn't been set needs to actually be implemented as described with an appropriate directory being calculated at the time that req.add_handler() is called with that directory being recorded as needing to be searched for the module. In changing the code though, if old and new importers are going to be supported during a transition phase, it must detect when the new module importer is being used and only do this when it is, as otherwise it will screw up how modules are found for the old importer. -- 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
[jira] Work started: (MODPYTHON-155) req.add_handler() and inheritance of directory to be searched for module
[ http://issues.apache.org/jira/browse/MODPYTHON-155?page=all ] Work on MODPYTHON-155 started by Graham Dumpleton. req.add_handler() and inheritance of directory to be searched for module Key: MODPYTHON-155 URL: http://issues.apache.org/jira/browse/MODPYTHON-155 Project: mod_python Issue Type: Sub-task Components: importer Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 The documentation for req.add_handler() says: Optional dir is a string containing the name of the directory to be added to the pythonpath. If no directory is specified, then, if there is already a handler of the same type specified, its directory is inherited, otherwise the directory of the presently executing handler is used. I there is a PythonPath directive in effect, then sys.path will be set exactly according to it (no directories added, the dir argument is ignored). This comment about the directory being inherited from the prior or currently executing handler is actually bogus as the code does not do anything specific at all to try and implement such behaviour. If it works this way at all it is partly by luck as what will actually dictate where the module specified to the req.add_handler() method is found is the current order of directories specified in sys.path. Since additional directories added into sys.path by the old importer can be performed in effectively random order, behaviour could actually be quite random if the same module name were used in multiple directories. Because the new importer doesn't add directories into sys.path for Python*Handler directives, a problem will currently arise if no directory is supplied to req.add_handler(). Specifically, a module may not be able to be found. This is because it can no longer fall back on to fact that with old module importer, the directory corresponding to the Python*Handler directive would be listed in sys.path somewhere. Thus, the documented behaviour for req.add_handler() when the directory hasn't been set needs to actually be implemented as described with an appropriate directory being calculated at the time that req.add_handler() is called with that directory being recorded as needing to be searched for the module. In changing the code though, if old and new importers are going to be supported during a transition phase, it must detect when the new module importer is being used and only do this when it is, as otherwise it will screw up how modules are found for the old importer. -- 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
Core Vote (Re: mod_python 3.2.9 available for testing)
Sorry for the late response - I was trying to have a vacation - that's when you are geographically in a different place with slow internet access and read only some of your e-mail ;-) +1 for core vote (with the note about the 2.2.2 XP SP2 issue). Grisha On Sat, 8 Jul 2006, Graham Dumpleton wrote: On 08/07/2006, at 4:26 AM, Jim Gallacher wrote: Hi Grisha, Here is the tally: +1 FreeBSD 6.1-RELEASE-p2, Apache 2.2 (mpm-prefork), Python 2.4.3 +1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5 +1 Linux Debian Sid, Apache 2.2.0 (mpm-worker), Python 2.4.2 +1 Linux Fedora Core 5 (i386), Apache 2.2.0 (mpm-prefork), Python 2.4.3 +1 Linux Slackware 10.2, Apache 2.0.55 (mpm-prefork), Python 2.4.1 +1 Linux Ubuntu 6.06, Apache 2.0.55 (mpm-worker), Python 2.4.3 +1 MacOSX 10.4.6 PPC, Apache-2.0.55 (mpm/worker), Python-2.3.5 +1 MacOSX 10.4.6 PPC, Apache-2.2.1 (mpm/worker), Python-2.3.5 +1 MacOSX 10.4.7 Intel, Apache-2.0.55 (mpm/prefork), Python-2.4.2 +1 Windows XP SP2, Apache 2.0.58 (mpm_winnt), Python 2.4.3 -1 Windows XP SP2, Apache 2.2.2 (mpm_winnt), Python 2.4.3 The -1 was from Nicolas, with the following comment: Only two tests fail but with a segfault, it's test_srv_register_cleanup and test_apache_register_cleanup. This is not really surprising... I think we should go ahead and release the 3.2.9 version, while filing a known bug regarding the fact that we drop the support for those two functions. If we accept this, then it's a +1. The issue with server cleanups failing and why is covered by: http://issues.apache.org/jira/browse/MODPYTHON-109 The last test results were submitted July 1, so I think we may as well have a core vote. Jim Gregory (Grisha) Trubetskoy wrote: I'm barely keeping my head above water right now with work, so not really following the list - if someone could please ping me when/if you think we're ready for the core group vote and we have a tally. Thanks! Grisha -- Forwarded message -- Date: Sat, 01 Jul 2006 23:18:05 -0400 From: Jorey Bump [EMAIL PROTECTED] To: python-dev@httpd.apache.org Subject: Re: mod_python 3.2.9 available for testing +1 Linux Slackware 10.2, Apache 2.0.55 (mpm-prefork), Python 2.4.1 Jim Gallacher wrote: The mod_python 3.2.9 tarball is available for testing. This tarball is unchanged from 3.2.9-rc3, but should be retested anyway - just in case something went pair-shaped in the process of tagging and packaging. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://people.apache.org/~jgallacher/mod_python/dist/ http://people.apache.org/~jgallacher/mod_python/dist/ mod_python-3.2.9.tgz http://people.apache.org/~jgallacher/mod_python/dist/ mod_python-3.2.9.tgz.md5 Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Apache, Apache-mpm, Python, the test output, and suggestions, if any). Please present your test results in the following format: +1 OS version, Apache version (apache mpm), Python Version For example: +1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5 Presenting your information in a consistent format will help in tabulating the results. You can include additional information in each section, just don't use extra commas. There is no need to include the mod_python version in this string as that information is available in the email subject. Who knows, one day I may actually write a script to extract this information automatically. :) Thank you for your assistance, Jim Gallacher
