Re: [mp2] Problem with custom config in Location
On Fri, 20 May 2005, Stas Bekman wrote: Herve, you've uncovered a bloody global perl context switch bug. Please try this patch (the reproducing tar ball now works for me under worker) This test does run successfully with your patch. Now define two directives. Use one inside the Location, another outside, and core dumps again. Test tarball attached. Thanks Herve. Please try this patch on top of the one I've sent before. Works so far for me with your new patch. Thanks,
Re: [mp2] Problem with custom config in Location
Herve, you've uncovered a bloody global perl context switch bug. Please try this patch (the reproducing tar ball now works for me under worker) This test does run successfully with your patch. Now define two directives. Use one inside the Location, another outside, and core dumps again. Test tarball attached. Thanks Herve. Please try this patch on top of the one I've sent before. Works so far for me with your new patch. Now I have a new problem with the patched version: no way to get the value of the configuration directive at the server level. New test tarball attached. bug-report.tgz Description: Binary data
Re: Is mod_perl installed
Cfaust, What does your httpd.conf file say after the modules listing? If it says something like: # #load configfiles from the config directory /etc/httpd.conf.d # Include conf.d/*.conf # Then check there for your: perl.conf file. Within the perl.conf file you will find: LoadModule perl_module modules/mod_perl.so Then look for the perl_module in /etc/httpd/modules. This is standard placement for Redhat Linux RPMs. I have found that I can edit this perl.conf to customize my modPerl and directories and script aliases On Thu, 2005-05-19 at 14:49 -0400, cfaust-dougot wrote: Hey Stas, I know this has been asked a ton of time and I have read everything on the site to check if MP is installed - my problem now is I have a client who has told me over and over again that mod_perl is installed - every method documented on the site says it is not (string doesn't appear in the error log, via telnet to apache or via the lwp-request method, it also doesn't appear via httpd -l. All method above report only Apache/2.0.46 (Red Hat) configured The box is RH enterprise and Apache and MP2 were installed via RPM - the client called RH (to prove me wrong) and RH told him if you installed MP2 via the RH RPM then that MP2 line shouldn't appear anyplace... I find that really hard to believe BEFORE I wasn't able find anything documented about it.. Is that true? So I guess my question is, can it be said with 100% certainty that the mod_perl 1.99 should show up in the error log (or those other documented methods) if its installed and configured properly? Is there any other ways to prove its installed or not installed? Thanks -Chris
[mp2] porting older mp2 code to 2.0.0 - I'm stuck with params from apreq!
I'm porting my code to mp2.0.0 from 1.99.older (16?) - so
far mostly ok, but I'm stuck on a conversion with
apreq - I've now got libapreq2-2.05-dev installed (the
distributed version, not sucked from svn/cvs).
I was using the following code to grab input :
sub hash_post {
# returns a hash of all the POST values
use Apache::Request;
my ($r) = shift;
my %rethash = {};
my $req = Apache::Request-new($r);
my @param_names = $req-param;
foreach my $value (@param_names) {
$rethash{$value} = $req-param($value);
}
return %rethash;
}
It's crude, but it worked with mp1.99 and libapreq 2.04-dev.
I've been floundering around with libapreq 2.05-dev
tryin to get at the params, but I don't really know
what I'm doing - and I haven't been able to find any
simple examples in the apreq code - save for some
pretty hairy stuff in glue/perl/t/apreq/cgi.t, but isn't
apreq supposed to hide all that bucket brigade stuff? I
just want the params from my POST and GET requests!
Can anyone suggest what simple change I need to make to the
above to get it working with mp2.0.0/libapreq-2.05-dev?
thanks!
Carl
Re: [mp2] porting older mp2 code to 2.0.0 - I'm stuck with params from apreq!
Carl Brewer wrote: If I'd looked in : docs/html/group__apreq__xs__request.html I'd have seen that all I needed to do was to change use Apache::Request; to use Apache2::Request; and my $req = Apache::Request-new($r); to my $req = Apache2::Request-new($r); and it would have just worked! Mea Culpa Carl
[mp2] OR_EXEC_ON_READ
did this go away? i can't find any mention of it in the source other than the documentation and core module logic. i'm currently playing with making a container configuration, and the documentation says to set OR_EXEC_ON_READ on the req_override, but it doesn't appear to be present in Apache2::Const. bizarre. .dorian
svn commit: r171257 - /perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm
Author: randyk
Date: Sat May 21 14:34:14 2005
New Revision: 171257
URL: http://svn.apache.org/viewcvs?rev=171257view=rev
Log:
use utime $now, $now, $file;, rather than utime undef, undef, $file;,
as on perl-5.8.0 on Win32 the latter causes an uninitialized value warning.
Modified:
perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm
Modified: perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm
URL:
http://svn.apache.org/viewcvs/perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm?rev=171257r1=171256r2=171257view=diff
==
--- perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm (original)
+++ perl/modperl/trunk/t/lib/TestAPRlib/finfo.pm Sat May 21 14:34:14 2005
@@ -34,8 +34,17 @@
# On Win32, touch the file to ensure it is in the same Daylight Saving
# Time season as the current time to workaround a bug in Win32's stat()
# which APR::Finfo allows for, otherwise the two disagree.
+#
+# With perl-5.8.0 on Win32, the syntax
+# utime undef, undef, $file;
+# causes an uninitialized warning to be emitted,
+# so use the equivalent
+# utime $now, $now, $file;
+# instead.
+#
if (WIN32) {
-utime undef, undef, $file;
+my $now = time;
+utime $now, $now, $file;
}
my $pool = APR::Pool-new();
