Re: [RFC] running tests after the server stops
The only issue is with Test::Harness, we will need to somehow feed tests to it so it'll take them all as one bunch, while we have to run first t/pre-start/ test, followed by normal tests, followed by t/post-stop/ tests. oh, I see the issue now. if we call TestRun::run_tests multiple times, each set of tests is sent to Test::Harness as a batch. so, calling it pre and post run results in three sets of reports. I have the start of an implementation now (working via t/TEST) but am hesitant to work on it more unless we think that three reports is ok for this feature. there will also have to be some trickery involved - if one set returns failure the remaining sets don't run - but I'm not sure where to put it. at any rate, the remaining issues are probably trivial if we can accept a change in output. if not, I'm not sure how this would work. --Geoff
Re: [RFC] running tests after the server stops
Geoffrey Young wrote: The only issue is with Test::Harness, we will need to somehow feed tests to it so it'll take them all as one bunch, while we have to run first t/pre-start/ test, followed by normal tests, followed by t/post-stop/ tests. oh, I see the issue now. if we call TestRun::run_tests multiple times, each set of tests is sent to Test::Harness as a batch. so, calling it pre and post run results in three sets of reports. I have the start of an implementation now (working via t/TEST) but am hesitant to work on it more unless we think that three reports is ok for this feature. there will also have to be some trickery involved - if one set returns failure the remaining sets don't run - but I'm not sure where to put it. It's actually good, it'd be bad if it'd continue running and users seeing success report from the last batch and missing failures from previous reports. e.g. in modperl-2.0, we already have two separate reports, the core and the registry, and registry tests won't run if the core test suite fails. at any rate, the remaining issues are probably trivial if we can accept a change in output. if not, I'm not sure how this would work. OK, here is an idea how to solve it. instead of starting and stopping the server by t/TEST delegate it to a specially designed tests. So the last test in t/pre-start/ will start the server and the first test in t/post-stop/ will stop the server. Both can be autogenerated. Of course this will mess up with the ability to run a single test with t/TEST, but we can instruct t/TEST to start the server if it doesn't see t/pre-start/ in the list of tests, and stop it if it doesn't see t/post-stop/ in the list of tests. __ 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
[patch] have_min_apache_version: 2.0.48-dev is not 2.0.48
Since 2.0.48-dev is not 2.0.48 I believe we should look at it as 2.0.47 in
the tests? or should we not complicate things and have those who use -dev
always keep up with the latest versions? I'm not sure if this should go in.
Index: Apache-Test/lib/Apache/Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.68
diff -u -r1.68 Test.pm
--- Apache-Test/lib/Apache/Test.pm 16 Sep 2003 07:38:13 - 1.68
+++ Apache-Test/lib/Apache/Test.pm 19 Sep 2003 19:43:14 -
@@ -259,12 +259,32 @@
}
}
+# since 2.0.48-dev is not 2.0.48, but more like 2.0.47
+# this returns the current apache version as is and the real one
+sub _apache_versions {
+my $cfg = Apache::Test::config();
+
+my $current = ;
+my $real= ;
+if ($cfg-{server}-{version} =~ m:^Apache/((\d)\.(\d+)\.(\d+)(-dev)?):) {
+$current = $1;
+# 2.0.48-dev = 2.0.47
+# 2.1.0-dev = 2.0.999
+# 2.1.1-dev = 2.1.0
+$real = $5
+? $4 0 ? ($2.$3. . ($4-1)) : ( $2. . ($3-1) . .999)
+: $current;
+}
+
+warn APACHE VERSION: $current, $real\n;
+return ($current, $real);
+}
+
sub have_min_apache_version {
my $wanted = shift;
-my $cfg = Apache::Test::config();
-(my $current) = $cfg-{server}-{version} =~ m:^Apache/(\d\.\d+\.\d+):;
+my ($current, $real) = _apache_versions();
-if ($current lt $wanted) {
+if ($real lt $wanted) {
push @SkipReasons,
apache version $wanted or higher is required, .
this is version $current;
@@ -277,10 +297,9 @@
sub have_apache_version {
my $wanted = shift;
-my $cfg = Apache::Test::config();
-(my $current) = $cfg-{server}-{version} =~ m:^Apache/(\d\.\d+\.\d+):;
+my ($current, $real) = _apache_versions();
-if ($current ne $wanted) {
+if ($real ne $wanted) {
push @SkipReasons,
apache version $wanted or higher is required, .
this is version $current;
__
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
Re: cvs commit: httpd-2.0/docs/manual/misc relevant_standards.html.en relevant_standards.xml
Roy T. Fielding wrote: dta href=http://www.rfc-editor.org/rfc/rfc2617.txt;RFC 2617/a - (Draft standard)/dt + (Standards Track)/dt IETF standards track: Internet Draft Proposed Standard Draft Standard Standard 2617 is a Draft Standard, like 2616. Doh, sorry. Can someone please ( re-)correct it? I have currently no cvs access from here... Thanks. nd
Re: Input filter and setting HTTP headers in Apache 2.0
[EMAIL PROTECTED] wrote: The only way I can see where I will have the ability to insert those HTTP inbound request headers is if my filter runs between the CORE_IN and the HTTP_IN input filter, I'm afraid this is true... Does anyone else have a better idea? in which case I will need a properly populated request_rec* structure to be able to use the ap_XXX APIs (typical things would be get the mime-type, content-length of the POST data, protocol version, etc). No, just modify the protocol data... If you want to insert a specific header field, just construct the text form of it as if the brower sent it and return it to the filter on top at the right point in the data stream. You're going to be keeping up with data you've read anyway so you can return it at the right time to the calling filter. Be careful you have configuration to avoid buffering the entire .iso file that somebody tries to copy to their DAV filesystem. And your configuration may be roll-your-own w.r.t. selecting which request objects to operate on since you may have to make your decisions before Apache has read the entire request header. Since my filter will run before the HTTP_IN filter would have had a chance to parse the request line and the request headers, it will most likely cause confusion within the Apache internal state. The simple answer is that if you return data in the right format to HTTP_IN, then there won't be a problem :) But keep track of Apache 2 development in that area so that if the interface has to change between those filters you can accomodate. I'm doubtful that the exact division of labor between the different Apache-provided input filters can be considered a stable programming interface.
Re: mod_info question
Aryeh Katz wrote: In mod_info, SERVER_CONFIG_FILE is used in order to determine which config file the apache server is running with However, this ignores the -f option. Shouldn't we be printing out ap_conftree-filename? that sounds right to me... got a patch you have tested that I can play with? (this time with old file on left and new file on right ;) )
Re: Input filter and setting HTTP headers in Apache 2.0
Be careful you have configuration to avoid buffering the entire .iso file that somebody tries to copy to their DAV filesystem. And your configuration may be roll-your-own w.r.t. selecting which request objects to operate on since you may have to make your decisions before Apache has read the entire request header. Could you perhaps please expand a bit on this? The simple answer is that if you return data in the right format to HTTP_IN, then there won't be a problem :) But keep track of Apache 2 development in that area so that if the interface has to change between those filters you can accomodate. I'm doubtful that the exact division of labor between the different Apache-provided input filters can be considered a stable programming interface. Point taken.
Re: mod_info question
Aryeh Katz wrote:
In mod_info, SERVER_CONFIG_FILE is used in order to determine which
config file the apache server is running with However, this ignores
the -f option. Shouldn't we be printing out ap_conftree-filename?
that sounds right to me... got a patch you have tested that I can
play with? (this time with old file on left and new file on right ;)
Sorry about that last patch :-(
Patch below was tested and it worked in a linux environment.
# diff -u mod_info.old.c mod_info.c
--- mod_info.old.c Mon Sep 15 07:48:59 2003
+++ mod_info.c Mon Sep 15 07:50:18 2003
@@ -405,7 +405,7 @@
ap_rprintf(r, dtstrongServer Root:/strong
tt%s/tt/dt\n, ap_server_root);
ap_rprintf(r, dtstrongConfig File:/strong
- tt%s/tt/dt\n, SERVER_CONFIG_FILE);
+ tt%s/tt/dt\n, ap_conftree-filename);
ap_rputs(/dlhr /, r);
}
for (modp = ap_top_module; modp; modp = modp-next) {
---
Aryeh Katz
Secured-Services Inc.
Re: cvs commit: httpd-2.0/docs/manual/misc relevant_standards.html.en relevant_standards.xml
On 19/09/2003, at 08:45, André Malo wrote: Roy T. Fielding wrote: dta href=http://www.rfc-editor.org/rfc/rfc2617.txt;RFC 2617/a - (Draft standard)/dt + (Standards Track)/dt IETF standards track: Internet Draft Proposed Standard Draft Standard Standard 2617 is a Draft Standard, like 2616. Doh, sorry. Can someone please ( re-)correct it? I have currently no cvs access from here... Thanks. nd Done. Cheers, Erik
Re: retire cvs modules (moved from PMC)
On Thu, 18 Sep 2003, William A. Rowe, Jr. wrote: http://cvs.apache.org/ shows that we have a *lot* of repositories that are hard for newcomers to sort through (and consume quite a bit of space) - if we httpd'ers can help mop up - I'm sure our efforts are appreciated. For that reason, and just to make clear to people what are the current, in development, repositories, I'm +1 on moving all those (except httpd-pop) under a graveyard, but retaining public accessibility. That is really just a communication issue. I don't believe this would cause significant pain to anybody, since I can't imagine anybody is using those repositories on a regular basis. As far as tarring them up and sticking them on archive.apache.org, I don't believe there is any need. The one advantage is that all the crazy people who slurp up every repository on cvs.apache.org (by rsync or cvs) wouldn't get at them. But retaining our history in a more active form is, I believe, worth that price. (Ideally, I suppose, the CVS graveyard itself would fall under archive.apache.org. But I think we want to retain all cvs access under the cvs.apache.org name for simplicity. We can just provide a reference on the archive.apache.org homepage pointing people to the graveyard.) Joshua.
Re: Input filter and setting HTTP headers in Apache 2.0
[EMAIL PROTECTED] wrote: Be careful you have configuration to avoid buffering the entire .iso file that somebody tries to copy to their DAV filesystem. And your configuration may be roll-your-own w.r.t. selecting which request objects to operate on since you may have to make your decisions before Apache has read the entire request header. Could you perhaps please expand a bit on this? I made two assumptions, perhaps both bogus: a) you need to read the entire request body (POST data) before deciding what headers to add, if any b) you'll buffer the request body in memory 'til you get to the end of it and decide what to do b would be really bad since for a large post you'll crash the server trying to alloc so much storage, which is why you wouldn't buffer it in memory. -- The point about roll-your-own configuration is that you can't make use of Apache Location and Directory containers to tell your module whether it should do this expensive processing on the POST data since you have to decide whether or not to do it long before Apache http engine has determined the Location and Directory information.
any Perl history experts out there?
a.k.a. What should the apxs 2.0 require statement say? apxs says require 5.003; on an old Sun box with this installation: $ which perl /opt/LWperl/bin/perl $ perl -version This is perl, version 5.003 with EMBED built under solaris at Mar 12 1997 03:06:34 + suidperl security patch Copyright 1987-1996, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5.0 source kit. apxs fails to build a module, giving this error message from Perl: Can't modify stub in list assignment at /tmp/trawick/built/bin/apxs line 600, ne ar ); Line 600 has 597 # the '()=' trick forces list context and the scalar 598 # assignment counts the number of list members (aka number 599 # of matches) then 600 my $cntopen = () = ($before =~ m|^\s*[^/].*$|mg); 601 my $cntclose = () = ($before =~ m|^\s*/.*$|mg); This silly perl won't even allow var declaration on foreach :) foreach my $var (@list)
Re: retire cvs modules (moved from PMC)
At 10:30 AM 10/19/2003, Joshua Slive wrote: On Thu, 18 Sep 2003, William A. Rowe, Jr. wrote: http://cvs.apache.org/ shows that we have a *lot* of repositories that are hard for newcomers to sort through (and consume quite a bit of space) - if we httpd'ers can help mop up - I'm sure our efforts are appreciated. For that reason, and just to make clear to people what are the current, in development, repositories, I'm +1 on moving all those (except httpd-pop) under a graveyard, but retaining public accessibility. That is really just a communication issue. I don't believe this would cause significant pain to anybody, since I can't imagine anybody is using those repositories on a regular basis. As far as tarring them up and sticking them on archive.apache.org, I don't believe there is any need. The one advantage is that all the crazy people who slurp up every repository on cvs.apache.org (by rsync or cvs) wouldn't get at them. But retaining our history in a more active form is, I believe, worth that price. The question about apache-apr, apache-nspr and apache-2.0 is - are they a significant part of our history? These three I'd say no, they aren't - and should be tarred up for those interested in where Apache 2.0 might have gone instead. The same with httpd-proxy, since we moved that cvs history back into the httpd-2.0 tree (and having both - even in the graveyard cvs, is redundant.) Bill
Re: any Perl history experts out there?
On Fri, Sep 19, 2003 at 11:49:03AM -0400, Jeff Trawick wrote:
a.k.a. What should the apxs 2.0 require statement say?
apxs says require 5.003;
on an old Sun box with this installation:
$ which perl
/opt/LWperl/bin/perl
$ perl -version
This is perl, version 5.003 with EMBED
built under solaris at Mar 12 1997 03:06:34
+ suidperl security patch
Copyright 1987-1996, Larry Wall
Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
apxs fails to build a module, giving this error message from Perl:
Can't modify stub in list assignment at /tmp/trawick/built/bin/apxs line
600, ne
ar );
Line 600 has
597 # the '()=' trick forces list context and the scalar
598 # assignment counts the number of list members (aka number
599 # of matches) then
600 my $cntopen = () = ($before =~ m|^\s*[^/].*$|mg);
601 my $cntclose = () = ($before =~ m|^\s*/.*$|mg);
Wow. I thought anything older than 5.004 could be considered
dead and buried.
Try this:
my $cntopen = @{[($before =~ m|^\s*[^/].*$|mg)]};
Or this:
my $cntopen = 0;
while ($before =~ m|^\s*[^/].*$|mg) {
$cntopen++;
}
This silly perl won't even allow var declaration on foreach :)
foreach my $var (@list)
The 'my' can not be on the foreach line for Perl 5.003.
Just move it one line up.
my $var;
foreach $var (@list) {
...
}
Cheers,
Glenn
Re: any Perl history experts out there?
Glenn wrote:
On Fri, Sep 19, 2003 at 11:49:03AM -0400, Jeff Trawick wrote:
a.k.a. What should the apxs 2.0 require statement say?
+
/+\
+
+
+
apxs fails to build a module, giving this error message from Perl:
Can't modify stub in list assignment at /tmp/trawick/built/bin/apxs line
600, ne
ar );
Line 600 has
597 # the '()=' trick forces list context and the scalar
598 # assignment counts the number of list members (aka number
599 # of matches) then
600 my $cntopen = () = ($before =~ m|^\s*[^/].*$|mg);
601 my $cntclose = () = ($before =~ m|^\s*/.*$|mg);
Wow. I thought anything older than 5.004 could be considered
dead and buried.
Try this:
my $cntopen = @{[($before =~ m|^\s*[^/].*$|mg)]};
Or this:
my $cntopen = 0;
while ($before =~ m|^\s*[^/].*$|mg) {
$cntopen++;
}
thanks for the suggestions :)
the big picture is finding an educated guess at what the require
statement in apxs should say
I think it is safe to move it up to 5.004, but if anybody happens to
know more info about the failure above then we can make a better guess.
I sure don't want to go on an install frenzy to hone in on the right
level.
Re: mod_info question
Hi,
Patch below was tested and it worked in a linux environment.
# diff -u mod_info.old.c mod_info.c
--- mod_info.old.c Mon Sep 15 07:48:59 2003
+++ mod_info.c Mon Sep 15 07:50:18 2003
@@ -405,7 +405,7 @@
ap_rprintf(r, dtstrongServer Root:/strong
tt%s/tt/dt\n, ap_server_root);
ap_rprintf(r, dtstrongConfig File:/strong
- tt%s/tt/dt\n, SERVER_CONFIG_FILE);
+ tt%s/tt/dt\n, ap_conftree-filename);
ap_rputs(/dlhr /, r);
}
for (modp = ap_top_module; modp; modp = modp-next) {
just tested with NetWare and Win32 and works fine.
Would be nice to have that in 2.0.48 since it is a simple patch which shouldnt break
anything...
Guenter.
Re: any Perl history experts out there?
On Fri, Sep 19, 2003 at 02:05:39PM -0400, Jeff Trawick wrote:
Glenn wrote:
On Fri, Sep 19, 2003 at 11:49:03AM -0400, Jeff Trawick wrote:
a.k.a. What should the apxs 2.0 require statement say?
+
/+\
+
+
+
Heh. Ok. Let me try answering your actual question now. :-)
Perl 5.004 is needed to do
foreach my $var (@whatever) {
...
}
I'm not sure when
my $cntopen = () = ($before =~ m|^\s*[^/].*$|mg);
starts working. I'd guess 5.004 since I've been using this trick
for quite a while. Even so, I think following works with any Perl 5:
my $cntopen = @{[($before =~ m|^\s*[^/].*$|mg)]};
For more info:
man perl5004delta
man perl5005delta
man perl56delta
man perl561delta
...
man perl (for a complete list of perl-related man pages)
Cheers,
Glenn
Re: mod_info question
Günter Knauf wrote:
Hi,
Patch below was tested and it worked in a linux environment.
# diff -u mod_info.old.c mod_info.c
--- mod_info.old.c Mon Sep 15 07:48:59 2003
+++ mod_info.c Mon Sep 15 07:50:18 2003
@@ -405,7 +405,7 @@
ap_rprintf(r, dtstrongServer Root:/strong
tt%s/tt/dt\n, ap_server_root);
ap_rprintf(r, dtstrongConfig File:/strong
- tt%s/tt/dt\n, SERVER_CONFIG_FILE);
+ tt%s/tt/dt\n, ap_conftree-filename);
ap_rputs(/dlhr /, r);
}
for (modp = ap_top_module; modp; modp = modp-next) {
just tested with NetWare and Win32 and works fine.
ooh, great! you just saved me some time :)
I'll commit to 2.1-dev shortly...
Would be nice to have that in 2.0.48 since it is a simple patch which shouldnt break anything...
...and propose it for merging to the stable branch.
Re: any Perl history experts out there?
Glenn wrote:
On Fri, Sep 19, 2003 at 02:05:39PM -0400, Jeff Trawick wrote:
Glenn wrote:
On Fri, Sep 19, 2003 at 11:49:03AM -0400, Jeff Trawick wrote:
a.k.a. What should the apxs 2.0 require statement say?
I'm not sure when
my $cntopen = () = ($before =~ m|^\s*[^/].*$|mg);
starts working. I'd guess 5.004 since I've been using this trick
for quite a while. Even so, I think following works with any Perl 5:
my $cntopen = @{[($before =~ m|^\s*[^/].*$|mg)]};
I found an old perl 5.004 on an old OS/390 box and it didn't complain.
I'll update the require to 5.004.
For more info:
man perl5004delta
man perl5005delta
man perl56delta
man perl561delta
nice tip!! I didn't know about that...
Thanks,
Jeff
mod_so
so there was this pickup truck maker, and he sold a bunch of pickup trucks to people far and wide but some of those people just wanted the truck for the chassis, so they replaced the truck bed with a camper they bought from someone else many of these camper customers found out that when you turn on both burners on the stove in the camper, the whole truck blows up the camper customers then get pissed at the pickup truck maker
