Re: t/SMOKE on win32
On Fri, 3 Oct 2003, Stas Bekman wrote: > Stas Bekman wrote: > > Steve Hay wrote: > > > >> Does my patch work on Linux? If not then I have got it all wrong, and > >> we're not still staring at a Win32 problem. > > > > > > Can you please post a patch against the current cvs, not against another > > patch? Thanks. > > It just hit me. Nothing that happens on the client side affects the server > side's STD streams, since the two communicate over sockets. Are you sure that > the "Failed to dup" error is coming from the server and not from the client? > e.g change the server error message to something else just to make sure? I changed the message in mp2/src/modules/perl/modperl_io.c (about line 139) to something unique, and the Failed to dup DTDOUT: Permission denied error is coming from there. And, like Steve mentioned, it is coming from a select group of tests. I've tried now a couple of things, but without success: - redirecting STDOUT/STDERR to a temporary file within the parent, and then calling run3 as run3 $command, undef, undef, undef; which is supposed to inherit the parent's STDs. This worked fine on linux, but not on Win32. - instead of using IPC::Run3, I wrote an equivalent thing using Win32::Process, but ran into the same problem. > If it is happening on the server side, may be it happens > due to a previous request not restoring the overriden STD > stream at the end of its run? We have the error checking, > but it may fail nevertheless? It sounds like that might be happening, especially since it's on a predictable subset of tests (eg, apache/scanhdrs, but apache/constants is OK). I'll try to put it through the debugger to see if that sheds any light. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem building mp1 on Win32
Hi, During the course of testing mp1.29-rc1 I ran into a strange problem, probably Windows-specific, which I've seen before but never got to the bottom of. I have Apache 1.3.28 installed in C:\apache and Perl 5.8.1 in C:\perl5. The latter has all the paths in it's Config.pm pointing to C:\perl5 subdirs, and I have C:\perl5\bin on the PATH (and no other Perl directories on the PATH). I then extract the mp1 source archive into C:\Temp and run: perl Makefile.PL APACHE_SRC=C:/apache EAPI nmake nmake test Normally this works fine, but occasionally I get errors from "nmake". Under mp1.28 I sometimes get this at the start of the "msdev" command run by "nmake": Compiling... Apache.c Apache.xs(1966) : error C2115: '=' : incompatible types [...] Error executing cl.exe. mod_perl.so - 1 error(s), 1 warning(s) NMAKE : fatal error U1077: 'msdev' : return code '0x1' while under mp1.29-rc1 I got this at the end of the "msdev" command: Linking... Creating library Release/mod_perl.lib and object Release/mod_perl.exp perl_util.obj : error LNK2001: unresolved external symbol _Perl_croak_nocontext [...] Release/mod_perl.so : fatal error LNK1120: 42 unresolved externals Error executing link.exe. mod_perl.so - 180 error(s), 1 warning(s) NMAKE : fatal error U1077: 'msdev' : return code '0xb4' I've finally tracked down what triggers this behaviour (it's the same trigger in each case), but I can't explain why. If I have another Perl build installed in C:\perl then I get the above errors; if I haven't then I don't! I suspect that problem is also related to the fact that the other Perl build that I sometimes have in C:\perl is a threaded Perl (a la ActivePerl) whereas the one in C:\perl5 is non-threaded, hence the error regarding "Perl_croak_nocontext" when the wrong Perl setup gets picked up. (Basically, I prefer the non-threaded Perl for my production work with mp1, but I also have a threaded Perl kicking around for mp2 testing.) Presumably something from the C:\perl installation is being used (in preference to the C:\perl5 installation that should be being used) if it is present. Why does this happen? All I have to do is move C:\perl out of the way (say, to C:\perl.mp2) and it all works fine again. Also, why is there a difference between 1.28 and 1.29-rc1 in the way in which it breaks? Is that related to this change in the ChangeLog?: For Win32, keep drive letters in mod_perl.dsp to fix bug, reported by DH <[EMAIL PROTECTED]>, when compiling mod_perl in cases where Apache and Perl are on different drives [Randy Kobes]. It's not an urgent problem for me since I have a workaround, but mp's build process really shouldn't be picking up the "wrong" Perl. All the other CPAN modules I'm using (150+ !) build fine with the other Perl sitting in C:\perl, so why shouldn't mod_perl? - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Randy Kobes wrote: I've tried now a couple of things, but without success: - redirecting STDOUT/STDERR to a temporary file within the parent, and then calling run3 as run3 $command, undef, undef, undef; which is supposed to inherit the parent's STDs. This worked fine on linux, but not on Win32. I've got very confused over exactly what does work and what doesn't (just in simple Perl terms, leaving mod_perl out of it for now), so I wrote a few test scripts to clear things up. I've attached an archive of them. Each of the scripts test1.pl through test6.pl try to run another Perl script called command.pl which writes "Hello" to STDOUT and "Hi! from command.pl" to STDERR. The test scripts seek to capture STDOUT by a variety of means, leaving STDERR untouched just to see that the command.pl did actually run, and then print what they've captured. Here's what each test script does: test1.pl passes a scalar to run3 test2.pl redirects STDOUT to a scalar and has run3 inherit it test3.pl redirects STDOUT to a scalar and passes that scalar to run3 test4.pl passes a file to run3 test5.pl redirects STDOUT to a file and has run3 inherit it test6.pl redirects STDOUT to a file and passes that file to run3 and here's the results with IPCRUN3DEBUG set to 5: = C:\Temp>test1.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): capturing child stdout Hi! from command.pl run3(): $? is 0 run3(): reading child stdout to SCALAR run3(): read 5 bytes from child stdout: 'Hello' Captured 'Hello' from STDOUT Done C:\Temp>test2.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' Hi! from command.pl run3(): $? is 0 Captured '' from STDOUT Done C:\Temp>test3.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): capturing child stdout Hi! from command.pl run3(): $? is 0 run3(): reading child stdout to SCALAR Captured '' from STDOUT Done C:\Temp>test4.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): feeding child stdout to file 'C:\Temp\output.txt' Hi! from command.pl run3(): $? is 0 Captured 'Hello' from STDOUT Done C:\Temp>test5.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' Hi! from command.pl run3(): $? is 0 Captured 'Hello' from STDOUT Done C:\Temp>test6.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): feeding child stdout to file 'C:\Temp\output.txt' Hi! from command.pl run3(): $? is 0 Captured 'Hello' from STDOUT Done = So it seems that run3 works fine when passed a scalar or a file, i.e. as it is intended to be used (test1 & test4). But when we muck around doing redirections ourselves first and expect run3 to inherit those redirections, it only works for files (test5 & test6), not for scalars (test2 & test3)! In short, we should be safe using IPC::Run3 as it was intended to be used. The fact that test2 & test3 didn't work is maybe a bug in IPC::Run3, but, as Barrie has pointed out in another mail, there's not much point in using IPC::Run3 at all if you're mucking about with redirections yourself - IPC::Run3 was meant to save you all that bother. However, I've now tried mod_perl's SMOKE with TestSmoke.pm coded like test1 and test4 in turn, and neither one worked. So what's the difference? Is it that with mod_perl's SMOKE the command being run via run3 actually does some redirections itself? If I replace the command.pl used in the tests above with a version that redirects STDOUT before printing "Hello" to it and then restores it again afterwards, I find that test1 & test4 (the two "purest" tests which worked before) now fail to capture anything, i.e. with this: command.pl: === use strict; use warnings; my $savout; open $savout, '>&STDOUT' or die "Can't dup STDOUT: $!\n"; close STDOUT or die "Can't close original STDOUT: $!\n"; my $logout = ''; open STDOUT, '>', \$logout or die "Can't redirect STDOUT: $!\n"; print STDOUT 'Hello'; print STDERR "Hi! from command.pl\n"; close STDOUT or die "Can't close redirected STDOUT: $!\n"; open STDOUT, '>&', $savout or die "Can't restore STDOUT: $!\n"; close $savout or die "Can't close saved STDOUT: $!\n"; === we now get: = C:\Temp>test1.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): capturing child stdout Hi! from command.pl run3(): $? is 0 run3(): reading child stdout to SCALAR Captured '' from STDOUT Done C:\Temp>test4.pl run3(): running 'C:\perl5\bin\perl.exe C:\Temp\command.pl' run3(): feeding child stdout to file 'C:\Temp\output.txt' Hi! from command.pl run3(): $? is 0 Captured '' from STDOUT Done = I don't know if that should have worked or not. Does it help explain what is going on? I'm still confused, though, because the above didn't generated "Can't dup STDOUT" errors like SMOKE does. - Steve tests.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PRO
Re: t/SMOKE on win32
On Oct 6 2003, Steve Hay wrote: Randy Kobes wrote: test1.pl passes a scalar to run3 test2.pl redirects STDOUT to a scalar and has run3 inherit it Does open STDOUT, '>', \$logout; create a real filehandle at the OS level, or does it use I/O layers to redirect the perl script's output to a scalar? If it's not a real filehandle, system(), and thus IPC::Run3::run3(), can't pass it down to the child. test3.pl redirects STDOUT to a scalar and passes that scalar to run3 This works on linux, will test on Win32, rewriting the crucial line to: run3 [ $^X, "-leprint'hi'"], undef, \$logout, undef; In short, we should be safe using IPC::Run3 as it was intended to be used. The fact that test2 & test3 didn't work is maybe a bug in IPC::Run3, but, as Barrie has pointed out in another mail, there's not much point in using IPC::Run3 at all if you're mucking about with redirections yourself - IPC::Run3 was meant to save you all that bother. If test2.pl worked, then IPC::Run3 could be simplified greatly! test3.pl should work on Win32--as it seems to on Linux modulo my tweaks--as IPC::Run3 should be saving and reopening STDOUT yet again to redirect it to the scalar. This is the first time I've actually used open FOO, '>', \$bar; since it was introduced; that sort of gimmickry was one of the main reasons IPC::Run was suggested and written :). - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Randy Kobes wrote:
On Fri, 3 Oct 2003, Stas Bekman wrote:
If it is happening on the server side, may be it happens
due to a previous request not restoring the overriden STD
stream at the end of its run? We have the error checking,
but it may fail nevertheless?
It sounds like that might be happening, especially
since it's on a predictable subset of tests (eg,
apache/scanhdrs, but apache/constants is OK). I'll
try to put it through the debugger to see if that
sheds any light.
I'm not sure that it's related to the actions of previous requests
because it happens with a single test which only makes one request.
I've been trying to debug what goes on when I run this:
perl t/SMOKE modperl\post_utf8
This single test is one of those that fails with the "Failed to dup
STDOUT" error. I've put a break point on the line that fails and a
pause near the start of the test script itself so that I can attach the
debugger to Apache.exe when the test script starts up. The one and only
time that the breakpoint is visited is the time that it fails. At this
point the call stack is:
=
modperl_io_perlio_override_stdout(interpreter * 0x011fa0f4, request_rec
* 0x03386160) line 137
modperl_response_handler_cgi(request_rec * 0x03386160) line 918 + 13 bytes
ap_run_handler(request_rec * 0x03386160) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x03386160) line 401 + 9 bytes
ap_process_request(request_rec * 0x03386160) line 288 + 9 bytes
ap_process_http_connection(conn_rec * 0x0084c650) line 293 + 9 bytes
ap_run_process_connection(conn_rec * 0x0084c650) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x0084c650, void * 0x0084c588) line 213
worker_main(long 0) line 731
_threadstartex(void * 0x0028d2c8) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=
I stepped into the Perl_do_open() call, and into Perl_do_openn().
Around line 106 of Perl (5.8.1)'s doio.c we have:
/* If currently open - close before we re-open */
if (IoIFP(io)) {
...
}
It may or may not be relevant to note that the above if-block was
skipped over. Does that imply that STDOUT is actually closed at this
point after all?
Continuing walking through Perl_do_openn() we visit line 389 (with dodup
set to 2):
fp = PerlIO_fdupopen(aTHX_ that_fp, NULL, dodup);
[which returns via line 536 of perlio.c] and later on line 555:
fd = PerlIO_fileno(fp);
which sets fd to 35 (!). We then go to line 561:
if (PerlLIO_fstat(fd,&PL_statbuf) < 0) {
and then it all goes wrong because sadly that PerlLIO_fstat() fails and
we return FALSE via lines 563, 564, 697, etc. The PerlLIO_fstat() call
actually winds up being _fstati64() on line 500 of win32/win32sck.c, and
returned -1.
Does any of this help anyone divine what is going wrong?
I also tried running the script with I/O tracing on. Here's what I get
in the error_log:
modperl_io.c:99: start
modperl_io_apache.c:57: done
modperl_io_apache.c:32: mode r
modperl_io_apache.c:71: did nothing
modperl_io.c:118: end
modperl_io.c:131: start
Failed to dup STDOUT: Permission denied.
The first start ... end section is modperl_io_perlio_override_stdin();
then we start modperl_io_perlio_override_stdout() and croak() straight
away. Doesn't really tell me much either :-(
What else can I try?
- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
Simon Flack wrote:
On Tue, 30 Sep 2003 11:49:57 -0700, Stas Bekman wrote
Simon Flack wrote:
Problem:
at the beggining of each request PERL5LIB is prepended to @INC in
reverse order. E.g.:
SetEnv PERL5LIB "one:two:three:four"
results in this:
@INC = ('four', 'three', 'two', 'one', '/usr', '...');
Environment:
Tested with perl 5.6.1, mod_perl 1.27 and 1.28
A patch is attached to src/modules/perl/perl_util.c that adds the
PERL5LIB
variables in the correct order.
Thank you Simon.
It's a bug indeed. However I think we can't change this
functionality in mp1 at this point, since it'll break other people's
setups which rely on the current behavior. We probably should
document this mis-feature.
Stas,
That's fine. Although the behaviour has changed as recently as v1.27 where
previously the contents of PERL5LIB were pushed onto @INC rather that
unshifted.
Well, the fix in 1.27 was different:
PERL5LIB support now properly unshifts paths into @INC rather than push
[Tatsuhiko Miyagawa <[EMAIL PROTECTED]>]
before 1.27, PERL5LIB was getting appended to @INC, instead of being
prepended. As a side effect it got the values in PERL5LIB reversed, but at
least they are coming in before the hardcoded @INC.
The problem with the current behaviour is that you need a special case when
running under mod_perl. In our set up, we test our scripts as CGIs and with
Apache::Registry and it's nice to be able to set PERL5LIB in one place rather
than two.
On the second thought, chances are that nobody has been using a multiple-paths
PERL5LIB, otherwise they would have complained like you did. So if nobody
objects and we agree that the current behavior is buggy, +1 for your patch.
So what do you think, fix it? or document it?
and of course need to fix that in mp2.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MP2] problem with command line args to perl Makefile.PL (includes patch)
Andrew Wyllie wrote: (I'm resending this as I did not see it go through the first time) I was running into a problem trying to build MP2 with a name other than mod_perl.so. After poking around for a while I found that the MP_LIBNAME arg on the command line was not replacing the default value of mod_perl.so, but just appending it. So if I specify something like: perl Makefile.pl MP_LIBNAME=mod_perl-2.0_cvs I get back something like: mod_perl dso library will be built as mod_perl mod_perl_1.99.10.so mod_perl static library will be built as mod_perl mod_perl_1.99.10.a Anyway, I patched lib/ModPerl/BuildOptions.pm so that you can tell the script whether you want to append the command line arg or replace it. The patch is included here, but someone should check to make sure that the options I have selected as appendable/replaceable are in fact such. Looks like your choice is good. And thanks for the patch, Andrew. Do you mind to cleanup up the patch to conform with our style guide (no tabs, indent 4, and a few other small bits): http://perl.apache.org/docs/2.0/devel/core/coding_style.html#Coding_Style_Guide If not, I'll do that a bit later and commit it. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Steve Hay wrote:
[...]
Any luck with either of the two following patches?
Index: src/modules/perl/modperl_io.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.c,v
retrieving revision 1.14
diff -u -r1.14 modperl_io.c
--- src/modules/perl/modperl_io.c 3 Oct 2003 17:45:23 - 1.14
+++ src/modules/perl/modperl_io.c 6 Oct 2003 19:12:11 -
@@ -173,6 +173,8 @@
Perl_croak(aTHX_ "Failed to restore STDIN: %_", get_sv("!", TRUE));
}
+Perl_do_close(aTHX_ handle, FALSE);
+
IoFLUSH_off(handle); /* STDIN's $|=0 */
MP_TRACE_o(MP_FUNC, "end\n");
@@ -193,6 +195,8 @@
if (status == 0) {
Perl_croak(aTHX_ "Failed to restore STDOUT: %_", get_sv("!", TRUE));
}
+
+Perl_do_close(aTHX_ handle, FALSE);
MP_TRACE_o(MP_FUNC, "end\n");
}
Index: src/modules/perl/modperl_io.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.c,v
retrieving revision 1.14
diff -u -r1.14 modperl_io.c
--- src/modules/perl/modperl_io.c 3 Oct 2003 17:45:23 - 1.14
+++ src/modules/perl/modperl_io.c 6 Oct 2003 19:13:25 -
@@ -164,7 +164,7 @@
MP_TRACE_o(MP_FUNC, "start");
-/* Perl_do_close(aTHX_ handle_orig, FALSE); */
+Perl_do_close(aTHX_ handle_orig, FALSE);
/* open STDIN, "<&STDIN_SAVED" or die "Can't dup STDIN_SAVED: $!"; */
status = Perl_do_open9(aTHX_ handle_orig, "<&", 2, FALSE, O_RDONLY,
@@ -173,6 +173,8 @@
Perl_croak(aTHX_ "Failed to restore STDIN: %_", get_sv("!", TRUE));
}
+Perl_do_close(aTHX_ handle, FALSE);
+
IoFLUSH_off(handle); /* STDIN's $|=0 */
MP_TRACE_o(MP_FUNC, "end\n");
@@ -185,7 +187,7 @@
MP_TRACE_o(MP_FUNC, "start");
-/* Perl_do_close(aTHX_ handle_orig, FALSE); */
+Perl_do_close(aTHX_ handle_orig, FALSE);
/* open STDOUT, ">&STDOUT_SAVED" or die "Can't dup STDOUT_SAVED: $!"; */
status = Perl_do_open9(aTHX_ handle_orig, ">&", 2, FALSE, O_WRONLY,
@@ -193,6 +195,8 @@
if (status == 0) {
Perl_croak(aTHX_ "Failed to restore STDOUT: %_", get_sv("!", TRUE));
}
+
+Perl_do_close(aTHX_ handle, FALSE);
MP_TRACE_o(MP_FUNC, "end\n");
}
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
On the second thought, chances are that nobody has been using a multiple-paths PERL5LIB, otherwise they would have complained like you did. So if nobody objects and we agree that the current behavior is buggy, +1 for your patch. So what do you think, fix it? or document it? and of course need to fix that in mp2. +1 on fixing it to behave properly in mp1. I'll tacked the mp2 bits this week. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
Geoffrey Young wrote: On the second thought, chances are that nobody has been using a multiple-paths PERL5LIB, otherwise they would have complained like you did. So if nobody objects and we agree that the current behavior is buggy, +1 for your patch. So what do you think, fix it? or document it? and of course need to fix that in mp2. +1 on fixing it to behave properly in mp1. I'll tacked the mp2 bits this week. Should we try to squeeze it into 1.29? If so do we need another release candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I suggest that we release 1.29 as it is now. Then hopefully we will release 1.30 some time soon (including the PERL5LIB fix). I know there are quite a few patches that Philippe has planned to put in and we want them to sit in the cvs for some time to get people time to test it out well. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
Should we try to squeeze it into 1.29? If so do we need another release candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I suggest that we release 1.29 as it is now. Then hopefully we will release 1.30 some time soon (including the PERL5LIB fix). I know there are quite a few patches that Philippe has planned to put in and we want them to sit in the cvs for some time to get people time to test it out well. my advice would be to get 1.29 out soon, as it will be the first stable version of mod_perl specifically for 5.8.1. release 1.30 can come with those patches, and be released at a much more leisurely pace --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp1] 1.29 release candidate #1
Steve Hay wrote: Philippe M. Chiasson wrote: The mod_perl 1.29 release candidate #1 has arrived. It can be downloaded here: http://www.apache.org/~gozer/mp1/mod_perl-1.28_01-dev-rc1.tar.gz MD5 : 9f3e81dcdea7cdda3715631c25e446ef SHA1: 1d14efb2ad89750dabcb3780b92992c1b8744551 Passed all tests on WinXP/MSVC++6 with Apache 1.3.28/Perl 5.8.1. Is there any chance of getting a fixed up Apache::Reload module into this? I already have that module in my own Apache/Perl setup, but it never got fixed in the way that was discussed a while ago (to provide an "UndefOnReload" option like Apache::StatINC has), and it was definitely going to be put into mp1 & mp2 with that fix in it as a replacement for Apache::StatINC... There are various threads in which this was all discussed at length, e.g. http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105545899207827&w=2 http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105591352209314&w=2 What's the current situation on all this? I think the thread wasn't completed. We started discussing what's the proper way to undef things and how to re-use the code for mp1 and mp2, and ran out of steam. That was back in June. It's definitely something that needs to be resolved. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp1] 1.29 release candidate #1
Philippe M. Chiasson wrote: The mod_perl 1.29 release candidate #1 has arrived. It can be downloaded here: http://www.apache.org/~gozer/mp1/mod_perl-1.28_01-dev-rc1.tar.gz MD5 : 9f3e81dcdea7cdda3715631c25e446ef SHA1: 1d14efb2ad89750dabcb3780b92992c1b8744551 Passed all tests on WinXP/MSVC++6 with Apache 1.3.28/Perl 5.8.1. Is there any chance of getting a fixed up Apache::Reload module into this? I already have that module in my own Apache/Perl setup, but it never got fixed in the way that was discussed a while ago (to provide an "UndefOnReload" option like Apache::StatINC has), and it was definitely going to be put into mp1 & mp2 with that fix in it as a replacement for Apache::StatINC... There are various threads in which this was all discussed at length, e.g. http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105545899207827&w=2 http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105591352209314&w=2 What's the current situation on all this? - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new PerlDefaultPortHandler
hi all...
along with the map_to_storage hook, I noticed that there are two other
Apache hooks that don't have Perl counterparts: ap_hook_default_port and
ap_hook_http_method.
here is an implementation for the PerlDefaultPortHandler. unlike other
hooks, this one doesn't enter the request cycle by default - it's called
when ap_default_port is invoked (such as with ap_get_server_port, depending
on your server settings), giving modules a chance to alter the default port
via a callback. the only example I can find is in mod_ssl, where the hook
is used to reflect 443 over 80 as the default port.
while it may seem inconsequential now, I can see it being important for
protocol handlers someday (and the same with hook_http_method, however
misnamed). and besides, it's there in Apache so it should be there in Perl :)
anyway, patches for PerlMapToStorageHandler and PerlHttpMethodHandler
coming soon...
--Geoff
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvspublic/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.107
diff -u -r1.107 Code.pm
--- lib/ModPerl/Code.pm 1 Oct 2003 19:53:05 - 1.107
+++ lib/ModPerl/Code.pm 7 Oct 2003 06:40:32 -
@@ -18,7 +18,7 @@
my %handlers = (
Process=> [qw(ChildInit ChildExit)], #Restart PreConfig
Files => [qw(OpenLogs PostConfig)],
-PerSrv => [qw(PostReadRequest Trans)],
+PerSrv => [qw(PostReadRequest Trans DefaultPort)],
PerDir => [qw(HeaderParser
Access Authen Authz
Type Fixup Response Log Cleanup
@@ -217,7 +217,7 @@
my $ix = $self->{handler_index}->{$class}->[$i];
if ($callback =~ m/modperl_callback_per_(dir|srv)/) {
-if ($ix =~ m/AUTH|TYPE|TRANS/) {
+if ($ix =~ m/AUTH|TYPE|TRANS|PORT/) {
$pass =~ s/MP_HOOK_RUN_ALL/MP_HOOK_RUN_FIRST/;
}
}
Index: src/modules/perl/modperl_callback.c
===
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.60
diff -u -r1.60 modperl_callback.c
--- src/modules/perl/modperl_callback.c 2 Oct 2003 17:45:52 - 1.60
+++ src/modules/perl/modperl_callback.c 7 Oct 2003 06:40:32 -
@@ -82,9 +82,8 @@
/* ModPerl::Util::exit doesn't return an integer value */
status = OK;
}
-/* assume OK for non-http status codes and for 200 (HTTP_OK) */
-if (((status > 0) && (status < 100)) ||
-(status == 200) || (status > 600)) {
+/* assume OK for 200 (HTTP_OK) */
+if ((status == 200)) {
status = OK;
}
}
Index: t/response/TestApache/conftree.pm
===
RCS file: /home/cvspublic/modperl-2.0/t/response/TestApache/conftree.pm,v
retrieving revision 1.5
diff -u -r1.5 conftree.pm
--- t/response/TestApache/conftree.pm 29 Jan 2003 03:56:00 - 1.5
+++ t/response/TestApache/conftree.pm 7 Oct 2003 06:40:32 -
@@ -52,6 +52,12 @@
my $vhost_failed;
for my $vhost ($tree->lookup("VirtualHost")) {
+
+# temporary fix for foo.example.com ServerName override
+if (ref $vhost->{'ServerName'} eq 'ARRAY') {
+$vhost->{'ServerName'} = $vhost->{'ServerName'}[0]
+}
+
unless (exists $vhosts{$vhost->{'ServerName'}
|| $vhost->{'PerlProcessConnectionHandler'}}) {
$vhost_failed++;
Index: xs/maps/apache_functions.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/apache_functions.map,v
retrieving revision 1.64
diff -u -r1.64 apache_functions.map
--- xs/maps/apache_functions.map12 Jun 2003 23:27:03 - 1.64
+++ xs/maps/apache_functions.map7 Oct 2003 06:40:33 -
@@ -432,7 +432,7 @@
>ap_run_post_config
>ap_run_insert_filter
>ap_run_child_init
-?ap_run_default_port
+ap_run_default_port
?ap_run_http_method
>ap_run_create_connection
>ap_run_pre_connection
Index: xs/tables/current/ModPerl/FunctionTable.pm
===
RCS file: /home/cvspublic/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.123
diff -u -r1.123 FunctionTable.pm
--- xs/tables/current/ModPerl/FunctionTable.pm 26 Sep 2003 08:29:26 - 1.123
+++ xs/tables/current/ModPerl/FunctionTable.pm 7 Oct 2003 06:40:37 -
@@ -4718,6 +4718,16 @@
},
{
'return_type' => 'int',
+'name' => 'modperl_default_port__handler',
+'args' => [
+ {
+'type' => 'request_rec *',
+'name' => 'r'
+ }
+]
+ },
+ {
+'return_type' => 'int',
'name' => 'modperl_type_handler',
'args
