Re: mod_python 3.2.7 available for testing
Hi David, One thing I don't understand is why you have foreign PythonOption definitions in your test setup. Are you sure you have re-created a clean testconf.py file from testconf.py.in ? I've write a little bit of documentation in test/README, please try to follow it. It seems to me that the test failures all come from this strange test configuration. It looks like mod_python is interfering with some already existing filters, like MultiView. Note that there is a bug under Win32 which I should have reported way before... In some situation, when an exception is raised in mod_python during normal operation, Apache will segfault the next time is is stopped or restarted. It only occurs with a specific exception is raised, maybe when a handler module fails to load. The reason why I haven't reported it yet is that it only occured on my development computer, not my production servers, so I thought it was something caused by my setup. Apparently you have the same problem, hence the segfault when the Apache server is stopped. I'll have to investigate this problem more thoroughly. So please try to re-run the test in a clean slate environment. It'd be interesting to see why and how your current configuration contaminates the test configuration, though. Regards, Nicolas 2006/2/8, David Fraser [EMAIL PROTECTED]: Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 I know its already been decided, but I thought I'd add another test for Windows (seeing as Nicolas is the only one who has tested so far...) This was with the installers Nicolas built, running the tests out of svn version 375881 +1 Windows XP SP2, Apache/2.0.54, Python 2.4.1 Unfortunately I got a failure too: -1 Windows 2000 SP4, Apache/2.0.49, Python 2.3.3 This even incorporated Apache segfaults ... when trying to stop with server.register_cleanup and apache.register_cleanup Other failures: req.add_handler() when handler list is empty PythonOption override, remove and remove2 PythonOutputFilter test_internal In all, I got 6 failures on the first 45 tests and 3 on the last 6. The PythonOption test failures look like they're conflicting with some PythonOptions in my default Apache config (since the assertion errors include things like jToolkit and jLogbook), so this seems to be an error in the test setup that its not independent of that. The PythonOutputFilter test also seems to be a test error, as it is returning the *contents* of test.py in uppercase instead of TEST OK in uppercase... Similarly test_accesshandler_add_handler_to_empty_hl is returning the contents of test.py I wonder if the segfaults on cleanup relate to my Apache version, if so I can try upgrading. Am I doing something wrong in the testing? Logs attached (zipped as the inclusion of test.py a few times make them quite big)... David
Re: mod_python 3.2.7 available for testing
Nicolas Lehuen wrote: Hi David, One thing I don't understand is why you have foreign PythonOption definitions in your test setup. Are you sure you have re-created a clean testconf.py file from testconf.py.in ? I've write a little bit of documentation in test/README, please try to follow it. Hi Nicolas I don't understand this either. I followed the docs in test/README (I've checked and did that right). I just repeated the test using my patch to use a different service name (attached). This only generated one segfault and failed on the second cleanup test, but not the first... This behaviour seems repeatable (running the tests twice produced exactly the same results) It seems to me that the test failures all come from this strange test configuration. It looks like mod_python is interfering with some already existing filters, like MultiView. Yes, it does indeed seem that way. So from the point of view, these errors shouldn't hold up the release, as they seem to be problems in the test framework. I just thought I'd like to run them, so it seems a good time to try and solve them. Note that there is a bug under Win32 which I should have reported way before... In some situation, when an exception is raised in mod_python during normal operation, Apache will segfault the next time is is stopped or restarted. It only occurs with a specific exception is raised, maybe when a handler module fails to load. The reason why I haven't reported it yet is that it only occured on my development computer, not my production servers, so I thought it was something caused by my setup. Apparently you have the same problem, hence the segfault when the Apache server is stopped. I'll have to investigate this problem more thoroughly. Interesting that it seems to make a difference running under a different service name. I can try help track this down. So please try to re-run the test in a clean slate environment. It'd be interesting to see why and how your current configuration contaminates the test configuration, though. OK I'm busy setting up VMWare to try this - pretty sure it'll pass, so I'll try investigate whats getting the situation confused... Thanks for your feedback David Index: test/testconf.py.in === --- test/testconf.py.in (revision 375881) +++ test/testconf.py.in (working copy) @@ -18,6 +18,9 @@ # Path to the mod_python.so file, should be in the apache modules directory. MOD_PYTHON_SO=@MOD_PYTHON_SO@ +# Set SVCNAME if you want to test via the given service +SVCNAME= + # makes emacs go into python mode ### Local Variables: ### mode:python Index: test/test.py === --- test/test.py (revision 375881) +++ test/test.py (working copy) @@ -176,6 +176,7 @@ TESTHOME = testconf.TESTHOME MOD_PYTHON_SO = testconf.MOD_PYTHON_SO LIBEXECDIR = testconf.LIBEXECDIR +SVCNAME = testconf.SVCNAME SERVER_ROOT = TESTHOME CONFIG = os.path.join(TESTHOME, conf, test.conf) DOCUMENT_ROOT = os.path.join(TESTHOME, htdocs) @@ -299,12 +300,38 @@ f.write(\n# --APPENDED-- \n\n+append) f.close() +def installService(self,extra=''): + +print Installing Test Apache Service +httpd = quoteIfSpace(HTTPD) +config = quoteIfSpace(CONFIG) +cmd = '%s %s -k install -n %s -f %s' % (httpd, extra, SVCNAME, config) +print , cmd +os.system(cmd) +time.sleep(1) +self.httpd_installed = 1 + +def uninstallService(self,extra=''): + +print Uninstalling Test Apache Service +httpd = quoteIfSpace(HTTPD) +cmd = '%s -k uninstall -n %s' % (httpd, SVCNAME) +print , cmd +os.system(cmd) +time.sleep(1) +self.httpd_installed = 0 + def startHttpd(self,extra=''): +if SVCNAME: +self.installService(extra) print Starting Apache httpd = quoteIfSpace(HTTPD) config = quoteIfSpace(CONFIG) -cmd = '%s %s -k start -f %s' % (httpd, extra, config) + if SVCNAME: +cmd = '%s %s -k start -n %s' % (httpd, extra, SVCNAME) +else: +cmd = '%s %s -k start -f %s' % (httpd, extra, config) print , cmd os.system(cmd) time.sleep(1) @@ -315,7 +342,10 @@ print Stopping Apache... httpd = quoteIfSpace(HTTPD) config = quoteIfSpace(CONFIG) -cmd = '%s -k stop -f %s' % (httpd, config) + if SVCNAME: +cmd = '%s -k stop -n %s' % (httpd, SVCNAME) +else: +cmd = '%s -k stop -f %s' % (httpd, config) print , cmd os.system(cmd) time.sleep(1) @@ -337,6 +367,9 @@ self.httpd_running = 0 +if SVCNAME: +self.uninstallService() + class PerRequestTestCase(unittest.TestCase): appendConfig = \nNameVirtualHost *\n\n @@ -1872,6 +1905,8 @@ def
mod_python info on modules.apache.org
Hi Grisha, The mod_python information on modules.apache.org is badly out of date. It would be a good idea to update this for 3.2.7 http://modules.apache.org/search?id=220 Jim
[jira] Created: (MODPYTHON-125) Improvements associated with req.handler for type checker phase.
Improvements associated with req.handler for type checker phase. Key: MODPYTHON-125 URL: http://issues.apache.org/jira/browse/MODPYTHON-125 Project: mod_python Type: Improvement Components: core Versions: 3.3 Reporter: Graham Dumpleton One purpose of the type checker phase in Apache, as able to be hooked using the PythonTypeHandler directive, is to use it to make decisions as to which actual handler should be used to deliver up the content for a request. It is also intended to be used to set up attributes such as req.content_type, req.content_encoding and req.content_languages. An example of an Apache module which supplies a function for this phase is mod_mime. That module uses lookups based on content type as derived from request URL extension type, to specify which handler should be used to generate the content. Another is mod_negotiation, which performs other sorts of determinations based on the request extension. In mod_python, there are a few missing bits which would allow you to use mod_python to do the same sorts of things. These are that req.handler, req.content_encoding and req.content_languages are not writable. Of these the most important is probably req.handler. To illustrate how it might be used, imagine an Apache configuration for a directory of: PythonTypeHandler select_handler PythonHandler deliver_content Although the PythonHandler directive is specified here, it is never actually called. This is because the configuration doesn't specify either SetHandler or AddHandler directives. When the SetHandler directive is used, normally the Apache core would see it and trigger mod_python for the content handler phase. If AddHandler is instead used, it is mod_mime that would trigger mod_python be used if the extension matches that in the request URL. Instead of using either of these directives, what should instead be able to be done is that a handler associated with PythonTypeHandler could say that mod_python should be triggered for the content phase. This might be done something like: def typehandler(req): if os.path.splitext(req.filename)[1] == .py: req.handler = mod_python return apache.OK return apache.DECLINED You might even say exactly which handler should be called as well. def typehandler(req): if os.path.splitext(req.filename)[1] == .py: req.handler = mod_python req.add_handler(PythonHandler,mod_python.publisher) return apache.OK return apache.DECLINED Unfortunately, this doesn't work because req.handler isn't writable. With req.handler writable it does work and the handler associated with PythonHandler, or as specified using req.add_handler() will be executed for the content phase. Now the main intent of this JIRA issue is to make req.handler writable, but at the same time it is to highlight that for completeness, that req.content_encoding and req.content_languages should also probably be made writable as they are values which for example are modifed by mod_mime in this phase of processing. Note that req.content_type is already writable, which is another attribute which mod_mime modifies in this phase. -- 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] Commented: (MODPYTHON-125) Improvements associated with req.handler for type checker phase.
[ http://issues.apache.org/jira/browse/MODPYTHON-125?page=comments#action_12365686 ] Graham Dumpleton commented on MODPYTHON-125: Forgot to mention that req.content_languages is not documented in mod_python HTML documentation for request object. Improvements associated with req.handler for type checker phase. Key: MODPYTHON-125 URL: http://issues.apache.org/jira/browse/MODPYTHON-125 Project: mod_python Type: Improvement Components: core Versions: 3.3 Reporter: Graham Dumpleton One purpose of the type checker phase in Apache, as able to be hooked using the PythonTypeHandler directive, is to use it to make decisions as to which actual handler should be used to deliver up the content for a request. It is also intended to be used to set up attributes such as req.content_type, req.content_encoding and req.content_languages. An example of an Apache module which supplies a function for this phase is mod_mime. That module uses lookups based on content type as derived from request URL extension type, to specify which handler should be used to generate the content. Another is mod_negotiation, which performs other sorts of determinations based on the request extension. In mod_python, there are a few missing bits which would allow you to use mod_python to do the same sorts of things. These are that req.handler, req.content_encoding and req.content_languages are not writable. Of these the most important is probably req.handler. To illustrate how it might be used, imagine an Apache configuration for a directory of: PythonTypeHandler select_handler PythonHandler deliver_content Although the PythonHandler directive is specified here, it is never actually called. This is because the configuration doesn't specify either SetHandler or AddHandler directives. When the SetHandler directive is used, normally the Apache core would see it and trigger mod_python for the content handler phase. If AddHandler is instead used, it is mod_mime that would trigger mod_python be used if the extension matches that in the request URL. Instead of using either of these directives, what should instead be able to be done is that a handler associated with PythonTypeHandler could say that mod_python should be triggered for the content phase. This might be done something like: def typehandler(req): if os.path.splitext(req.filename)[1] == .py: req.handler = mod_python return apache.OK return apache.DECLINED You might even say exactly which handler should be called as well. def typehandler(req): if os.path.splitext(req.filename)[1] == .py: req.handler = mod_python req.add_handler(PythonHandler,mod_python.publisher) return apache.OK return apache.DECLINED Unfortunately, this doesn't work because req.handler isn't writable. With req.handler writable it does work and the handler associated with PythonHandler, or as specified using req.add_handler() will be executed for the content phase. Now the main intent of this JIRA issue is to make req.handler writable, but at the same time it is to highlight that for completeness, that req.content_encoding and req.content_languages should also probably be made writable as they are values which for example are modifed by mod_mime in this phase of processing. Note that req.content_type is already writable, which is another attribute which mod_mime modifies in this phase. -- 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
