Re: [proposal] remove [EMAIL PROTECTED]
Justin Erenkrantz wrote: I'd like to propose shutting down [EMAIL PROTECTED] and move it all back under [EMAIL PROTECTED] The traffic on [EMAIL PROTECTED] list doesn't justify a separate list, and the Apache-Test code is now property of the Apache::Perl PMC, so discussions of that are now elsewhere too. All that's really left is just httpd's test cases (which really should be done in view of [EMAIL PROTECTED] anyway) and flood (which, like mod_mbox, might get more lovin' if any posts on it moved to [EMAIL PROTECTED]). Any objections? If no one screams, I'll do it next week. +1 it would be nice if rather than alias [EMAIL PROTECTED] to [EMAIL PROTECTED] the message bounced with some kind of informational message about the new breakdown - we still get A-T questions directed toward [EMAIL PROTECTED] for people who haven't figured out the proper place yet, and I'm just not paying as much attention to [EMAIL PROTECTED] as I used to or ought... --Geoff
Re: PHP testing - problem with php libraries loading
Chris Shiflett wrote: Hi Filin, I've tride a lot of variants and I even think that IfModule @PHP_MODULE@ php_admin_value extension_dir /usr/lib/php4/ /IfModule _should_ work - but it doesn't! I don't know why :( (I tried both t/extra.conf.in and t/conf/extra.conf.in) The latter is the correct place. You might try getting rid of the conditional statement, just to see if that's the problem. hmm, that's a good point. t/conf/extra.conf.in only affects php tests that run inside the server, such as t/response/TestAPI/foo.php. if you're using t/foo.php-style tests then settings in t/conf/extra.conf.in don't apply. guess we need to figure out how to do that... --Geoff
Re: PHP testing - problem with php libraries loading
cc'ing chris :) I think a line in the t/conf/php.ini: extension_dir = ./ means that php seeks libraries in the current directory, while those libraries are in the /usr/lib/php4/. hmm, could be. chris would know better. Thereby I have 2 questions: 1) Why it is necessary to have a special php.ini for testing? for the same reason that Apache-Test maintains all its own configuration files, really - consistency, principle of least surprise, and so on. think of it like this... say you have code that works one system and doesn't work on another. the problem turns out to be that your php.ini file contains a crucial difference, but one you didn't think was crucial. if your tests relied on the installed php.ini file then you'd have the exact same problem on each box when running the tests, on one box it would fail and on one box it would pass. this is Very Bad from a testing point of view - tests should create a very specific environment in which to exercise your code, one where all the variables are known. using our own php.ini file (and own httpd.conf, etc) means that the described circumstance would never happen - the tests would pass on both systems letting you know immediately that your production environment is _not_ the same as your testing environment. and that is Good from a testing point of view. 2) How can I test (in a sane manner) php code with functions from dynamic libraries? I don't know the specifics, but to alter any php.ini setting you would create t/conf/extra.conf.in and use a php variable to override the default settings in php.ini I've tried to copy mysql.so in the current directory, in all meanings of current which I could imagine but without any success. I've successfully tried to modify the Apache::TestConfigPHP so that it generates now 'extension_dir=/usr/lib/php4/', but I don't think it is a good solving... no, anything you need to override you can do locally from t/extra.conf.in, such as IfModule @PHP_MODULE php_extension_dir /usr/lib/php4/ /IfModule or somesuch - I'm not really a php guy :) chris has links to the sample tarball where you can see tricks like this in action. unfortunately we haven't had the free tuits to document it as well as we would have liked. but then again, nobody seemed to be using the php side of things but us. so, welcome - we hope you like it :) --Geoff
Re: Cryptic error when LWP isn't available
Justin Erenkrantz wrote: httpd-test gives a really cryptic error message when LWP isn't installed: Use of uninitialized value in concatenation (.) or string at .../Apache-Test/lib/Apache/TestHarness.pm line 121. Be nice if we could fix that. It seems that $_ is trounced by $self-run_t(). My perl-fu doesn't have an elegant solution other than saving $_ before run_t() and then restoring it after. After I did that, I got the 'LWP isn't available' warnings. *light bulb* Once I installed LWP, the error disappeared for whatever reason. Does anyone with perl-fu have a real solution? I'll figure one out sometime today or tomorrow. thanks for reporting it :) --Geoff
Re: getting config file in TestConfigParse.pm
If $file does exist, then the
if (! -e $file -e $default_conf) {
}
is ignored, but the
else {
}
will be followed; in my case, on Win32, it overwrote the correct,
exisiting $file with
$file = catfile $root, $default_conf;
blarg, sorry about that.
which didn't exist. The following patch:
looks good.
--Geoff
Re: svn commit: r290157 - /httpd/test/trunk/perl-framework/c-modules/test_ssl/mod_test_ssl.c
So with 2.1.7 $r-ext_lookup(2.16.840.1.113730.1.13) should return This Is A Comment for any SSL vhost in the test suite if it works properly. excellent! thanks so much for the info. --Geoff
Re: svn commit: r290157 - /httpd/test/trunk/perl-framework/c-modules/test_ssl/mod_test_ssl.c
+#ifdef HAVE_SSL_EXT_LOOKUP
if (!ext_lookup) {
ap_rputs(ssl_ext_lookup not available, r);
return OK;
}
hey, speaking of this ext_lookup, can you give me an example of what this
function does? in Apache::SSLLookup I've added perl glue for this method,
and right now I've got 2 forms:
my $client_foo = $r-ext_lookup($something, 1);
my $server_foo = $r-ext_lookup($something);
but I really could never figure out what to glean from the generated ssl
certificates to test against, what to pass as $something, etc.
ideas?
--Geoff
Re: style update part III
-my ($self, $user, $uid, $gid) = @_; +my($self, $user, $uid, $gid) = @_; eew, the mod_perl style guide doesn't really say that, does it? that's awful. --Geoff
Re: ApacheCon Europe and http://httpd.apache.org/test/
Philip M. Gollucci wrote: Jim Martinez wrote: Who maintains http://httpd.apache.org/test/ ? There's a image on it that reads ApacheCon Europe 2005 that links to the ApacheCon US 2005 (via a redirect). ApacheCon Europe 2005 was, according to the web site, held around July 18th, 2005. Most likely the image should be changed to something applicable for ApacheCon US 2005 (maybe a nonexistent logo). looks like that link isn't part of test/ proper, but rather part of the global httpd site nav - it also shows up on /, for example. anyway, I think that the folks who really spend the time on httpd.apache.org design will fix it when they find some tuits. I believe anyone that is an httpd committer can change it. I think that's right. speaking of which, the real Apache-Test homepage is here http://perl.apache.org/Apache-Test/ anyone looking for something to contribute back might spend some time sprucing it up - IIRC there is already an infrastructure in place to support Apache-Test/api Apache-Test/user/perl Apache-Test/user/php etc --Geoff
Re: ApacheCon Europe and http://httpd.apache.org/test/
I saw that.. The link of perl.apache.org is blank though right ? I'm not quite with the program yet... what do you mean? httpd.apache.org/test links to perl.apache.org/Apache-Test. --Geoff
[ANNOUNCE] Apache-Test 1.26
The URL http://people.apache.org/~geoff/Apache-Test-1.26.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.26.tar.gz size: 147976 bytes md5: 0626e18f95e36b61b035e7485295128e --Geoff Changes since 1.25: make sure mp2 loading doesn't make it impossible to complete mp1 runs. [Matt Sergeant, Geoffrey Young] add Apache::TestConfigParrot and Apache::TestRunParrot to support mod_parrot server-side testing [Geoffrey Young] update -withtestmore action to properly work with newer versions of Test::Builder [Geoffrey Young]
Re: Unable to run t/ssl tests.
William A. Rowe, Jr. wrote: Well now; rm -rf t , and svn up, gives me the original error attempting to create 'serial', a 'serial.old' lingers during the config phase. after nuking t/ make sure to nuke ~/.apache-test (or whatever it is on win32) and run with APACHE_TEST_NO_STICKY_PREFERENCES=1 from now on to make sure that things aren't lingering around when they shouldn't. other than that, I'll have a look on monday, but I'm not a win32 guy :) --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder)
Too late to run INIT block at C:/Perl/site/lib/Devel/Cover.pm line 153. Too late to run CHECK block at C:/Perl/site/lib/Devel/Cover.pm line 155. don't worry about those. The only interesting line in t/logs/error_log is: [Mon Jul 18 14:32:40 2005] [error] [client 127.0.0.1] failed to resolve handler `TestMore::testmorepm': Can't dup STDERR: Bad file descriptor at C:/Perl/lib/Test/Builder.pm line 1218. that looks like it's out of my control. maybe randy has more insights? waiting 60 seconds for server to start: .Syntax error on line 382 of C:/code/htt pd-test/perl-framework/t/conf/extra.conf: Invalid command 'DAVLockDB', perhaps mis-spelled or defined by a module not incl uded in the server configuration If I comment out the webdav section from t/conf/extra.conf.in, the tests can run (with errors, but that's another matter). odd, since those directives are in a IfModule mod_dav.c block, so I wouldn't think it would hit those directives without being able to process them. hmm... does t/conf/httpd.conf (which is autogenerated) have something like Loadmodule dav_module mod_dav.dll Addmodule mod_dav.c ? or maybe mod_dav is compiled in statically but is incomplete? maybe Dav On is missing? sorry, but I'm not a dav user, so I don't know the gory details of that module. --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
Stas Bekman wrote: Geoffrey Young wrote: Now, this looks like a bug. The T::B-reset method expects an object, Apache::Test calls it as a class method. I allow for the possibility that I've completely misunderstood everything--or even just some things. well, it's not exactly a bug - it looks like Test::Builder changed reset() from a class method to an object method since that code was written. I guess I'll need to fix that :) Or may be just move the branch that bundles T-M in into the trunk? This problem has been fixed in that branch if I remember correctly. well, I want to run that branch through a battery of tests before we go and merge it into trunk - I, for one, have quite a bit of testing code that relies on proper Test::More support, so if that all ends up working we're probably good to go. has this issue been resolved yet? http://marc.theaimsgroup.com/?l=apache-modperl-test-devm=111512322421210w=2 --Geoff
Re: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
Now, this looks like a bug. The T::B-reset method expects an object, Apache::Test calls it as a class method. I allow for the possibility that I've completely misunderstood everything--or even just some things. well, it's not exactly a bug - it looks like Test::Builder changed reset() from a class method to an object method since that code was written. I guess I'll need to fix that :) --Geoff
[ANNOUNCE] Apache-Test 1.22
we are pleased to announce the latest Apache-Test release, 1.22. the important change to note for this release is that mod_perl support is incompatible with mod_perl versions 1.999_21 and earlier. in other words if you are a mod_perl user only upgrade to this release if you also plan to upgrade to mod_perl 2.0-RC5 (1.999_22). users of the other parts of the distribution (TestRun, TestRunC, TestRunPHP) should be unaffected. now for the details... The URL http://people.apache.org/~geoff/Apache-Test-1.22.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.22.tar.gz size: 144807 bytes md5: e62ddf036ae8ab69bf52f20336a656bb --Geoff Changes since 1.21: IMPORTANT this version of Apache-Test does not completely configure mod_perl for mod_perl versions 1.99_21 or earlier. Please read the below changes carefully. *** remove Apache::TestConfig::modperl_2_inc_fixup(). Apache-Test is no longer Apache2.pm aware - it will not configure mod_perl support to look in Apache2/ automatically. [joes] Add support for mp2's Apache:: - Apache2:: rename [joes] The URL http://people.apache.org/~geoff/Apache-Test-1.22.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.22.tar.gz size: 144807 bytes md5: e62ddf036ae8ab69bf52f20336a656bb
Re: [ANNOUNCE] Apache-Test 1.22
Stas Bekman wrote: Geoffrey Young wrote: we are pleased to announce the latest Apache-Test release, 1.22. the important change to note for this release is that mod_perl support is incompatible with mod_perl versions 1.999_21 and earlier. by earlier Geoff meant 1.99_xx .. 1.999_20 (the mp2-tobe versions). It doesn't affect mod_perl1 users. yes, quite sorry about that :) --Geoff
[ANNOUNCE] Apache-Test 1.21
The URL http://cvs.apache.org/~geoff/Apache-Test-1.21.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.21.tar.gz size: 144796 bytes md5: dc8b26adc5717e94435479604e74fdfc Changes since 1.20: fix Apache::TestConfig (was missing 'use lib' before using lib::import) [William McKee [EMAIL PROTECTED]] TestConfigPerl will now configure mod_perl last, giving mod_perl highest priority throughout the httpd lifecycle. [Geoffrey Young] Apache::TestConfig::untaint_path needs to remove empty entries in the PATH list, since -T considers those tainted too. [Stas] add Apache::TestHarnessPHP which allows for running client-side scripts via php instead of perl. [Geoffrey Young]
[RELEASE CANDIDATE] Apache-Test 1.21
a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. --Geoff Changes since 1.20: fix Apache::TestConfig (was missing 'use lib' before using lib::import) [William McKee [EMAIL PROTECTED]] TestConfigPerl will now configure mod_perl last, giving mod_perl highest priority throughout the httpd lifecycle. [Geoffrey Young] Apache::TestConfig::untaint_path needs to remove empty entries in the PATH list, since -T considers those tainted too. [Stas] add Apache::TestHarnessPHP which allows for running client-side scripts via php instead of perl. [Geoffrey Young]
Re: [Fwd: MODERATE for modperl-cvs@perl.apache.org]
I've approved joe as a poster. Geoff, why the moderation hits the modperl-cvs /at/ perl.apache.org list? I dunno. ask set these up. pinging ask now :) Also it looks that commits to A-T go to two lists: To: [EMAIL PROTECTED], modperl-cvs@perl.apache.org any special reason? I didn't do it. I'll ping justin. fixed - thanks justin :) --Geoff
Re: Apache-Test subdirectory has moved
yay, php docs at perl.apache.org :) they may be more popular, but I think we still win when it comes to open-source altruism :) sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? I'm all for it! cool. I'm going to spend some time over the next few days trying to get this situated, then. should there be Apache-Test/dist too? or should the CPAN distribution be sufficient? we can do that, although http://search.cpan.org/dist/Apache-Test/ is just as good. but if we want to mirror the way we do mod_perl then we can have dist/ as well, no problem. also we may want to add a /Apache-Test/snapshot for svn-impaired users. that's a good idea. I'll see if I can find the snapshot scripts or talk to whoever I need to to get that setup. --Geoff
Re: loading mod_perl first?
This solution looks good to me, but should be mod_embperl.c instead of Embperl.c. well, I went to the embperl site and added this to my httpd.conf LoadModule embperl_module /tmp/Embperl.so and things worked out as expected [ debug] /tmp/Embperl.so is already absolute [ debug] /tmp/Embperl.so successfully resolved to existing file /tmp/Embperl.so [ debug] Found: embperl_module = Embperl.c [ debug] Skipping LoadModule of Embperl.c is this not a correct setup? or it is for apache2 and not apache 1.3? --Geoff
Re: [Fwd: MODERATE for modperl-cvs@perl.apache.org]
Stas Bekman wrote: Folks committing to A-T, please don't forget to subscribe to the new lists: [EMAIL PROTECTED] [EMAIL PROTECTED] I think I mentioned that before, but it never hurts :) I've approved joe as a poster. Geoff, why the moderation hits the modperl-cvs /at/ perl.apache.org list? I dunno. ask set these up. Also it looks that commits to A-T go to two lists: To: [EMAIL PROTECTED], modperl-cvs@perl.apache.org any special reason? I didn't do it. I'll ping justin. --Geoff
Re: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? it probably should but it doesn't. just copy your modified files to someplace safe, do the update, then move then back. --Geoff
Re: Apache-Test subdirectory has moved
Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. --Geoff
Re: preload modules at sever startup
Jim Martinez wrote:
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
better [EMAIL PROTECTED] now, but that list was just created yesterday :)
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
if you can move it to t/lib/Foo/Bar.pm Apache-Test will pick it up.
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
yes. an equivalent in mp1 might be to do this in extra.conf.in
Perl
use lib qw(@ServerRoot@/../lib)
/Perl
or without the Perl sections from modperl_extra.pl.in, which is equivalent
to startup.pl but with @var@ substitution. you can use modperl_extra.pl if
you don't need substitution.
keep in mind that if you go this route you will probably need to change
extra.conf.in to extra.last.conf.in so that it is loaded _after_ your
startup.pl. see the bottom of the generated httpd.conf to see what I mean.
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
no, that's the idea. you just need to use the magic files :)
HTH
--Geoff
Re: loading mod_perl first?
may be we should be more flexible right away and use the same approach Apache uses, i.e. have each custom module a say for its insertion priority. So we could add mod_perl as middle module and give other modules an opportunity to load themselves before (first/very_first or after (last/very_last) mod_perl or some other module. It really shouldn't be mod_perl centric as more and more non-perl projects start to use A-T. well, I think this is kinda a mod_perl problem, since we're only talking about TestConfigurePerl and it's special treatment of mod_perl. if you use TestConfig or TestConfigPHP then the modules are just inherited from httpd.conf (mod_perl included) in the order in which they appear there, which is typically what the user wants. in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. So instead of printing the modules right away they could be assembled into an array which will be then resorted the way the user wants. e.g.: add_foo(, before = mod_perl.c); add_foo(, after = qw[mod_perl.c mod_proxy.c]); or have those before/after/last/first/etc encoded in the API instead... well, I think that for the most part inheriting order from httpd.conf is sufficient, at least for the moment, but we can always create a larger API later when time allows. for the moment, though, I think I'm happy to make an exception for embperl within TestConfigPerl. at least until somebody complains :) --Geoff
Re: loading mod_perl first?
Christopher H. Laco wrote:
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on
another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use
PerlModule not
LoadModule. embperl seems to be the exception to this. axkit would
be the
only other I could think of but I just verified that it uses
PerlModule as well.
Don't the new 2.x proxy modules have the same type of dependency?
mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
but I've never tried loading them out of order to see if they fail.
yeah, that seems to be the case. and apparently there are some things that
may require mod_dav as well.
but generally this isn't an issue, since we inherit the order, as well as
module location, from httpd.conf. of course, if mod_dav wanted to use
Apache-Test for its own development it wouldn't inherit from httpd.conf but
would create its own TestConfigDav.pm class to handle things for it.
what makes mod_perl unique in this circumstance is that we are making
exception for Embperl, which is really a third party module that we have no
control over - anybody can have a custom mod_foo that depends on mod_perl or
any other module, but that doesn't mean we need to account for it in
Apache-Test land.
anyway, I'm starting to think that the best solution is like the one I've
attached here, at least for the moment. what this means is that people with
Embperl in their httpd.conf won't have problems, while people wanting to
explicitly test Embperl will have to do what everyone else needs to do -
subclass TestConfig.pm and determine the module loading order themselves.
--Geoff
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
Re: Apache-Test subdirectory has moved
if you don't find any with grep, then there are none. So we should add one then :) :) yes, now that it's officially ours we should do more to publicise it. additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. that's cool. additionally I think we should have subdirectories for each of the supported languages /Apache-Test/perl /Apache-Test/php /Apache-Test/parrot (someday soon) and so on. in fact, it was the need for a home for php-related docs and whatnot that prompted this move in the first place ;) And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? yes, specifically under /Apache-Test/perl was what I was going to suggest. And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) yes. and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup good idea. from an .htaccess file or do we do that in the core httpd.conf? of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? --Geoff
loading mod_perl first?
hi all...
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first,
# so make sure that it's loaded before files inherited from the
# global httpd.conf
$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
what this does is load mod_perl.so ahead of all other modules, giving it
least priority. there are a few problems I see with this
- in 1.3 this is a _very_ untypical setup - mod_perl.so needs to be loaded
last so that it gets first crack at each phase.
- in 2.X order doesn't matter due to the new hooking API, but it _does_
matter for overriding directives. that is, you can't load mod_perl.so first
and get first crack at _directive_ parsing.
anyway, I guess what I'm saying is that 99% of the time we want mod_perl to
have the highest priority, but we do the exact opposite with Apache-Test,
which is probably ungood.
now, in all fairness to embperl I don't want to just yank this out without
giving gerald some alternative. however, I think it's a bad idea to create
a test environment that doesn't accurately represent the most common case.
so, here are some possible solutions...
- historically I think this was introduced before we had
extra.last.conf.in functionality. gerald, does using that file help you?
- we could provide for an extra argument to configure_libmodperl() which
would place mod_perl.so first instead of the (new) default of last. this
would allow folks like embperl to do something like
package My::TestConfigurePerl;
our @ISA = qw(Apache::TestConfigurePerl);
sub configure_libmodperl { shift-SUPER::configure_libmodperl(1) }
and have things work the way they did before. patch attached.
thoughts?
--Geoff
Index: lib/Apache/TestConfigPerl.pm
===
--- lib/Apache/TestConfigPerl.pm (revision 152675)
+++ lib/Apache/TestConfigPerl.pm (working copy)
@@ -29,6 +29,8 @@
sub configure_libmodperl {
my $self = shift;
+my $first = shift;
+
my $server = $self-{server};
my $libname = $server-version_of(\%libmodperl);
my $vars = $self-{vars};
@@ -94,10 +96,17 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+if ($first) {
+# modules like Embperl.so need mod_perl.so to be loaded first,
+# so make sure that it's loaded before files inherited from the
+# global httpd.conf
+$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+}
+else {
+# the default for most mod_perl installations - give mod_perl
+# highest priority by loading it last.
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
+}
}
Apache-Test subdirectory has moved
the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update to get the perl-framework running smoothly again. if you have any problems with access or permissions, just let me know and we'll get it sorted out. part of the reason we did this migration was to separate testing activities from the development of the Apache-Test engine. to that end, two new mailings lists were created: [EMAIL PROTECTED] [EMAIL PROTECTED] so, if you want to follow Apache-Test development you will want to subscribe to one or both of those mailing lists via sending an empty email to [EMAIL PROTECTED] [EMAIL PROTECTED] although I suspect that we will all be following [EMAIL PROTECTED] as well, the use of the new dev list is encouraged for ongoing discussions directly related to Apache-Test. --Geoff
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
Geoff, removing the SSLRequire line is right, it doesn't really matter though... ok, done. thanks for the input. --Geoff
Re: svn commit: r148889 - /httpd/test/trunk/perl-framework/t/conf/ssl/ssl.conf.in /httpd/test/trunk/perl-framework/t/ssl/fakeauth.t
So Geoff is saying, you must try and at the next line you must also succeed. With SSLVerifyClient optional, the semantics would be instead Don't bother to insist for a certificate, but if user forgot it, give him flaming death. Considered inappropriate :-) i'm no expert here - I took the SSLRequire line from the test case on httpd-dev, while all the other tests use SSLVerifyClient so I kept it without really understanding things at all. http://marc.theaimsgroup.com/?l=apache-httpd-devm=110685418427430w=2 so, are you saying that can remove SSLVerifyClient here and all is ok? all I wanted was to exercise FakeBasicAuth + mod_auth_anon. --Geoff
Re: Apache2 / mod_perl1 confusion
Gavin Carr wrote: On Fri, Jan 21, 2005 at 09:26:53AM -0500, Geoffrey Young wrote: I'm trying to test a C module against both apache2 and apache1. apache1 is working beautifully, but when I attempt to reconfigure for apache2 (stock FC1), A::T (1.20) keeps complaining about finding mod_perl 1. I'm doing: ./TEST -clean ./TEST -apxs /usr/sbin/apxs -conf when I run tests against both apache 1 and apache 2 I generally 'make realclean' and then re- perl Makefile.PL -apxs... and it works just fine. if you look in t/TEST you'll probably see your old -apxs path in there. well, that is, if you specified -apxs when building your Makefile :) Since this is a C module I'm actually just using a static TEST like this: #!/usr/bin/perl use strict; use warnings FATAL = 'all'; use Apache::TestRunPerl; Apache::TestRunPerl-new-run(@ARGV); since it's just a C module and you don't need mod_perl you should change that Apache::TestRunPerl to just Apache::TestRun. that should make A-T use the inherited mod_perl from httpd.conf instead of hunting around for it. straight out of one of the A::T tutorials. you should check out the code from the tutorial I gave at ApacheCon. the code is here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development-code.tar.gz and the tutorial slides are here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development.pdf pay particular attention to mod_example_ipc-install in the code tarball. basically, put your C module in c-modules following the pattern you'll see there (filenames and directory names and declarations are important). then let Perl manage t/TEST and the Makefile for you using makefile. No change with APACHE_TEST_NO_STICKY_PREFERENCES=1, and I don't have a ~/.apache-test at all. Nothing actually ends up in t/conf after the -conf run either - it looks like it's just bailing out. hmm, that's odd. Any further suggestions of where to look? Might be perl debugger time ... I would start with copying the workflow I outline in the tarball I mentioned above. it's a bit different than what you're doing now, so it may feel strange, but give it a whirl and see if it works. then you can decide if you like it or not :) HTH --Geoff
Re: t/TEST -start-httpd -port=34343
http://perl.apache.org/docs/general/testing/testing.html#Parallel_Testing Here's what I see when I run t/TEST -start-httpd -port=34343 yeah, this is where Apache-Test gets confusing... it's '-port 34343' not '-port=34343'. same with '-port select'. this is different than, say '-trace=debug' where the = is required... basically, the first set of options from t/TEST -help use an equal sign and are part of Apache::TestRun. the second set _do not_ use an equal sign and are part of Apache::TestConfig. gotta love legacy decisions :) --Geoff
Re: A-T: httpd.conf.in
I think we should implement it, since if someone is very unhappy about the autogenerated httpd.conf they can supply their custom httpd.conf.in that feels like a lot of work to me - like making A-T respect the Port setting from httpd.conf.in, because that's what they would expect. I think that -httpd_conf, -httpd_conf_extra, and extra.conf.in should be more than enough for the vast majority of people. so +1 for just removing it from the README, but if you want to make it work, feel free. --Geoff
Re: Apache-Test
Stas Bekman wrote:
Geoffrey Young wrote:
In which case we need to remove the custom patterns we have added so
far?
hmm, did we actually add any, or just make the regex a bit more loose? I
can't recall.
can you see how Apache-PREFORK-AdvancedExtranetServer/2.0.52 matches 1?
That's because our code is completely broken, since this is bogus:
# Apache-AdvancedExtranetServer/1.3.29 (Mandrake Linux/1mdk)
($self-{rev}) ||= $self-{version} =~ m|^Apache.*?/(\d)\.|;
# IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
($self-{rev}) ||= $self-{version} =~ m|^.*?Apache.*?/(\d)\.|;
it always matches 1. It should be:
# Apache-AdvancedExtranetServer/1.3.29 (Mandrake Linux/1mdk)
($self-{rev}) ||= ($self-{version} =~ m|^Apache.*?/(\d)\.|);
# IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Unix)
($self-{rev}) ||= ($self-{version} =~ m|^.*?Apache.*?/(\d)\.|);
we have noticed that bug, since those patterns were written when testing
1.3 and of course it has matched 1 :)
yeah, I wish I had noticed before - it's a major gripe of mine that ||=
wrecks that match idiom.
Let's try first with a relaxed /x.y.zz, before we add yet another env var.
ok.
--Geoff
Re: [A-T patch] changing should_skip_module to support regex skip patterns
Stas Bekman wrote: As you can see from the email below, some modules embed a version number in the module 'mod_fastcgi-2.4.2-AP20.dll'. Our should_skip_module only matches an exact name. The patch at the end of this email extends the functionality to support regex skip arguments. Let me know if you have any objections to this change. +1 +$name =~ s/\.(s[ol]|dll)$/.c/; #mod_info.so = mod_info.c +$name =~ s/\.dll$/.c/; #mod_info.so = mod_info.c ? --Geoff
Re: A-T: testmore failures
so you are looking at encountering other problems, as you try to run modperl tests without using a correct environment. yeah, you're right. or something else needs to be done with t/more. yes. well, with Apache/Test.pm actually. this should be more helpful: Index: lib/Apache/Test.pm === --- lib/Apache/Test.pm (revision 122981) +++ lib/Apache/Test.pm (working copy) @@ -75,7 +75,7 @@ Test::More-import(@testmore); \Test::More::plan; -} or die -withtestmore error: $@; +} or print 1..0 # skipped: -withtestmore error [EMAIL PROTECTED] exit; # clean up arguments to export_to_level shift; of course, that will rely on a recent fix to mod_perl svn :) or not worry about it at all - t/more isn't in the MANIFEST, so it will only be a problem for people like us. I mean, we can spend tuits mucking around with it, but I don't think it's all that important, since -withtestmore is marked as useful but experimental anyway. Why not put it in a separate test suite then? That should be an easy thing to do, and Apache-Test already includes additional test suites since a few days. sure, that's fine. --Geoff
Re: A-T: testmore failures
the problem is simple - A-T's test suite doesn't use Apache::TestRunPerl, so all the special stuff needed by modperl is not used. So it picks the default module it finds (if any). in this case it picks the wrong mod_perl.so, and the server side ends up running under a different perl. yeah, well... it's not _my_ fault that the test checks for Test::More and mod_perl but the embedded mod_perl.so isn't the same :) So I think the only solution to this is enforce that A-T tests require installed modperl. I wouldn't want to do that - people other than mod_perl folks are using this and I wouldn't want to effectively say the tests can't be run unless you're using mod_perl, loser. or something else needs to be done with t/more. or not worry about it at all - t/more isn't in the MANIFEST, so it will only be a problem for people like us. I mean, we can spend tuits mucking around with it, but I don't think it's all that important, since -withtestmore is marked as useful but experimental anyway. --Geoff
Re: SVN release methodology : svn copy
svn copy https://svn.apache.org/.../trunk \ https://svn.apache.org/.../tags/1.17 (optionally with an -r to peg at specific revision, I guess) Yes, that's probably what we will have to end up doing in the future. if you can find the time, can you please make sure the RELEASE file is up to date so that the next person to release Apache-Test has no trouble doing the right thing? thanks :) --Geoff
Re: Apache-Test/Makefile.PL r105822
doesn't seem to be right. sub is a compile time directive, so putting it in a conditional doesn't prevent from it being compiled: indeed. guess I wasn't thinking, which seems to be happening lots lately. Moreover it now introduces a warning in mp2 build Subroutine MY::libscan redefined at ./Makefile.PL line 148. ugh. so we need to do the usual ugly workaround for MM :( usual? Can you fix those? I can do it if you don't have the time. well, I don't really have the time, but since it's my problem I'll take care of it. that is, if you can tell me exactly what needs to be done - I would probably just put the if logic inside the sub, but I suspect there needs to be more than that for mod_perl's sake? --Geoff
Re: need to require Cwd 2.06 for A-T
Stas Bekman wrote: Stas Bekman wrote: I know we tried to avoid external dependencies, but Cwd coming with 5.6.x is unusable under -T. At the moment this breaks some mp2 tests (the problem comes from A-T, which indirectly invokes Cwd::cwd via File::Spec's rel2abs. I've tried to code a workaround, but it doesn't work and it's a bad idea to get it working since it's very OS specific. (_backtick_pwd is the problem). so we probably have no choice but require Cwd 2.06 if it's only breaking mp2 tests then those tests should probably have plan tests = $n, need_min_module_version(Cwd = 2.06); instead of requiring an external dependency for the entire framework. not that I'm against external dependencies, but we should only require an external dependency when the codebase itself requires it. that is, it is your tests that need a higher Cwd, not Apache-Test proper. --Geoff
Re: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
--Geoff
Re: extending t_cmp to handle !t_cmp?
Am I correct to say that Test::More is in the core for all but 5.6.1 the required minimum by mp2? yes, but see below - we would have further version restrictions if we chose to make T::M the engine for the entire mp2 test suite. so if we make a dependency on Test::More only the 5.6.1 users will have to figure out how to get this module before they can start building modperl? they shouldn't need the dependency to build mod_perl, only to test it :) If we agree to go with the switch to T::M, do we have sufficient functionality with T::M shipped with 5.8.0 for example? i.e. is 5.6.1 the only perl version that we need to require users to do an extra operation or do we require a specific T::M version, in which case many other distros are affected? to use Test::More for server side tests (a la t/response/foo.pm) we need at least version 0.49, which was not even in 5.8.5. client tests can use any version of T::M as far as I know. so really, if you want unlike() (or whatever) you would need to do that on a per-test basis. otherwise you would essentially be preventing a large portion of the userbase from running the test suite as a whole. I'm not entirely convinced this is unacceptable, but I'm sure you are, so I'll give in here :) anyway, in the end I guess I wouldn't suggest moving to T::M entirely just yet. but if you want to use it occasionally within certain tests I think that's fine. I understand that Test::More's behavior is preferrably at run time, yeah, that's the issue for me - t_cmp() prints out too much cruft when everything is just fine. since it prints out the data only when there are problems. But how do you develop a new test if you have no way to force Test::More to print the compared values? I just trust is() - if you develop tests first then it always fails until you get things right :) That's the only reason why I prefer t_cmp() to is(). I can see that. --Geoff
Re: extending t_cmp to handle !t_cmp?
anyway, in the end I guess I wouldn't suggest moving to T::M entirely just yet. but if you want to use it occasionally within certain tests I think that's fine. Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. yeah, that's the issue for me - t_cmp() prints out too much cruft when everything is just fine. agreed, and we could certainly change that to match T::M's behavior, *but* I still want to be able to force it to print the verbose output even when everything is fine. yeah, that's a good idea. I prefer to first see the output and then write the comparison test than the other way around. I don't understand why T::M doesn't allow an option to force the verbose output. I dunno the politics here, but it might make for a nice enhancement. I'll look into it. --Geoff
Re: extending t_cmp to handle !t_cmp?
Stas Bekman wrote: Stas Bekman wrote: Of course another alternative is to bundle a sufficient version of T::M under t/. that's an idea. so long as it's not installed with 'make install'. or indexed by cpan either, I suppose. anything living under t/ is not installed on 'make install' and not scanned by PAUSE. The only request is to do that after mp2.0 is out. agreed. no sense in messing with that now. --Geoff
Re: Fwd: cvs commit: httpd-test/perl-framework/t/htdocs/security CAN-2004-0958.php
Cliff Woolley wrote: On Tue, 23 Nov 2004, Joe Orton wrote: Discussion of whether or not it's useful to have PHP tests in httpd-test can take place on test-dev@, please send your comments there and I'll follow up. I actually think it's useful to have php tests in our suite, because having a large number of tests for a module as big as php helps to flush out bugs in httpd (and maybe apr). That would be even more the case if php's sapi module for httpd 2.x that worked as a filter were in a reasonable state... now that TestRunPHP and TestConfigPHP are complete, I was considering moving the existing php tests over to this new framework. the advantage is that each individual test would get an ok marker at a granular level, rather than a simple ok that represented, say, 5 tests together in a lump. how does this sound to everyone? I'd probably get to it sometime over the next two weeks, and I'd post a major diff before going forward. --Geoff
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. each directory now has properties and one of those properties is which files to ignore. see http://svnbook.red-bean.com/en/1.0/apas06.html for metadata info in general, http://svnbook.red-bean.com/en/1.0/ch07s02.html for property foo, specifically grep for svn:ignore. for other useful cvs to svn migration stuff http://svnbook.red-bean.com/en/1.0/apa.html is helpful if you haven't already seen it. for me, I've found this entirely unintuitive, since I can't seem to find a way to _add_ files to ignore without first gleaning which are currently ignored from .svn/. that is, since there seems to be no propadd option, I'm left with recreating .cvsignore from .svn/dir-props, adding the new file to ignore, then slurping up .cvsignore svn propset. and I always seem to cause some sort of conflict when I want to set properties on . instead of a directory below it. so, if anyone has any pointers here, that would be great :) --Geoff
Re: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
The .cvsignore properties were automatically added into the svn:ignore properties by cvs2svn when the repos was converted, so when I removed the .cvsignore files that's all I did, nothing else needed tweaking. Great! so Geoff, that means you can drop the .cvsignore files in the mp2 tree I believe? done. --Geoff
time for Apache-Test 1.16
hi all... with the php hooks pretty much solidified, I would like to release A-T 1.16 before apachecon so that the presentation there is associated with an official release version. I plan on rolling a release candidate early next week, so if there is some work that you want to get into this release, now is the time :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
If I had to guess, this borks anything but gmake. Test for that. I had asked on #asf about this and somebody (I forget who) said that the make manpage on minortaur (some bsd variant) supports ?= as well. from looking at that it seems to be the manpage for pmake, which I guess is some other make variant. so limiting it to gmake at least would seem to wipe out bsd folks. a little digging on my own at the time made it seem like solaris make is really gmake, so between linux, solaris, and bsd a decent case was being made that most unix make variants to support the syntax. of course, that list of 3 was hardly exhaustive :) anyway, this just isn't my area, so I'm happy to defer to others that grok all this SA-type stuff. but if most unix-variants support ?=, or if there is another more universal way to work around the issue, I would hate to see the correct behavior only for unix people using gmake. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
a little digging on my own at the time made it seem like solaris make is really gmake Well, the way you have it installed perhaps. But attempting this against /usr/ccs/bin/make it most definately blows up. ok. I actually don't have a solaris box to try on - I just went to sun's support site and saw that the manpage for make was gmake (at least the one that google first pointed me toward :) , so between linux, solaris, and bsd a decent case was being made that most unix make variants to support the syntax. of course, that list of 3 was hardly exhaustive :) Hardly. The man page for hpux 11 make makes no mention of ?= nor does AIX 5.1. you are 2 for 5. yeah, not good. Explicitly fails on native make(s) on AIX 5.1, HPUX 11, Solaris 2.6. Please find another solution. well, the solution at the moment is to not have a solution - cvs has been reverted, so unless a real solution can be found it will remain a minor nit. p.s. simple test I used... TERM ?= uberterm all: echo $(TERM) the gmake manual suggests that ?= is equivalent to ifeq ($(origin TEST_VERBOSE), undefined) TEST_VERBOSE = 0 endif so that might make for a good test - the gmake manual didn't speficially say that origin was explicit to it, but then again it didn't mention ?= either :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
@
if (my $custom_config_path = custom_config_path()) {
debug loading custom config data from: '$custom_config_path';
$custom_config_loaded++;
+($candidate) = $candidate=~/^(.*)/; # launder for -T
require $custom_config_path;
huh?
something is definitely wrong here - there is no $candidate in the scope of
the current function, so this actually fails with errors.
$ perl Makefile.PL -apxs /apache/2.0/prefork/perl-5.8.5/bin/apxs
Global symbol $candidate requires explicit package name at
lib/Apache/TestConfig.pm line 2080.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote: geoff 2004/10/28 07:33:56 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: revert last change to keep things compiling sorry stas if you would have gotten to this quickly, but I thought it was a good idea to keep things in cvs compiling and gozer said you would be offline for a few days due to a crazy landlord or something :) --Geoff
Re: cvs commit: httpd-test/perl-framework/t/security CAN-2004-0940.t
[EMAIL PROTECTED] wrote: jorton 2004/10/25 06:04:14 Modified:perl-framework/t/conf extra.conf.in Added: perl-framework/t/htdocs/security CAN-2004-0940.shtml perl-framework/t/security CAN-2004-0940.t Log: Regression test for CAN-2004-0940, 1.3 mod_include overflow. hi joe :) I get the following failures on 1.3.32 but not on 1.3.33. t/modules/rewrite.t 222 9.09% 18 20 t/security/CAN-2004-0940.t11 100.00% 1 t/security/CAN-2004-0958.t92 22.22% 1 3 I think these are all recent additions from you. should each of these failures be skipped unless something like ( have_apache(1) have_min_apache_version(1.3.33) ) || ( have_apache(2) have_min_apache_version(2.0.XX) ) ? --Geoff
Re: cvs commit: httpd-test/perl-framework/t/conf extra.conf.in
[EMAIL PROTECTED] wrote: jorton 2004/10/12 06:53:41 Modified:perl-framework/t/modules rewrite.t perl-framework/t/conf extra.conf.in Log: Add test for RewriteRule [P] flag which is broken in HEAD due to mod_proxy changes. joe++ :) --Geoff
[ANNOUNCE] Apache-Test-1.14
The URL http://perl.apache.org/~geoff/Apache-Test-1.14.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.14.tar.gz size: 127197 bytes md5: d930b810b4e1b85325f3e3fd9cb93bd1 Changes since 1.13: improve the same_interpreter framework to handle response failures while trying to init and later find out the same interpreter. [Stas] make sure that 'make distclean' cleans all the autogenerated files [Stas] make sure that if -maxclients option is passed on the command line, minclients will never be bigger than that value [Stas] add -one-process runtime argument, which will start the server in single-server mode (httpd -X in Apache 1.X or httpd -D ONE_PROCESS in 2.X) [Geoffrey Young] In open_cmd, sanitize PATH instead of clearing it [Gozer] Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill [EMAIL PROTECTED]] Added an apxs query cache for improved test performance [Gozer] run_tests make target no longer invokes t/TEST -clean, making it possible to save a few development cycles when a full cleanup is not required between runs. [Geoffrey Young] Apache::TestSmoke imrovements: [Stas] o the command line option -iterations=N should always be respected (previously it was internally overriden for order!='random'). o since IPC::Run3 broke the Ctrl-C handler, we started to loose any intermediate results, should the run be aborted. So for now, try to always store those results in the temp file: smoke-report...$iter.temp fix 'require blib' in scripts to also call 'blib-import', required to have an effect under perl 5.6.x. [Stas] don't allow running an explicit 'perl Makefile.PL', when Apache-Test is checked out into the modperl-2.0 tree, since it then decides that it's a part of the modperl-2.0 build and will try to use modperl httpd/apxs arguments which could be unset or wrong [Stas] Fix skip test suite functionality in the interactive configuration phase [Stas] s/die/CORE::die/ after exec() to avoid warnings (and therefore failures) when someone overrides CORE::die when using Apache-Test [William McKee, Stas]
[RELEASE CANDIDATE] Apache-Test-1.14
a release candidate for Apache-Test 1.14 is now available. http://perl.apache.org/~geoff/Apache-Test-1.14-dev.tar.gz worthy of note is that this version ought to play nicely with Devel::Cover 0.49 with the use of -one-process, making it possible to get coverage results for mod_perl handlers. please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. --Geoff Changes since 1.13: improve the same_interpreter framework to handle response failures while trying to init and later find out the same interpreter. [Stas] make sure that 'make distclean' cleans all the autogenerated files [Stas] make sure that if -maxclients option is passed on the command line, minclients will never be bigger than that value [Stas] add -one-process runtime argument, which will start the server in single-server mode (httpd -X in Apache 1.X or httpd -D ONE_PROCESS in 2.X) [Geoffrey Young] In open_cmd, sanitize PATH instead of clearing it [Gozer] Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill [EMAIL PROTECTED]] Added an apxs query cache for improved test performance [Gozer] run_tests make target no longer invokes t/TEST -clean, making it possible to save a few development cycles when a full cleanup is not required between runs. [Geoffrey Young] Apache::TestSmoke imrovements: [Stas] o the command line option -iterations=N should always be respected (previously it was internally overriden for order!='random'). o since IPC::Run3 broke the Ctrl-C handler, we started to loose any intermediate results, should the run be aborted. So for now, try to always store those results in the temp file: smoke-report...$iter.temp fix 'require blib' in scripts to also call 'blib-import', required to have an effect under perl 5.6.x. [Stas] don't allow running an explicit 'perl Makefile.PL', when Apache-Test is checked out into the modperl-2.0 tree, since it then decides that it's a part of the modperl-2.0 build and will try to use modperl httpd/apxs arguments which could be unset or wrong [Stas] Fix skip test suite functionality in the interactive configuration phase [Stas] s/die/CORE::die/ after exec() to avoid warnings (and therefore failures) when someone overrides CORE::die when using Apache-Test [William McKee, Stas]
time for Apache-Test 1.14?
hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? --Geoff
Re: cvs commit: httpd-test/perl-framework/t/protocol nntp-like.t
Justin Erenkrantz wrote: --On Wednesday, September 29, 2004 10:26 AM +0100 Joe Orton [EMAIL PROTECTED] wrote: Yup, the t_cmp arguments were flipped a while back. FWIW, I think whomever flipped the t_cmp arguments but didn't flip the included test cases at the same time needs a stern talking to. I spent over an hour and a half figuring out why the heck httpd was returning a 200 in that case where a 413 was clearly (or at least more) correct: only to find out that the debug output was swapped. Incredibly, incredibly lame. yeah, well, that was me. it's difficult to find the time to do everything that needs doing. in this case, the order was swapped to be consistent with other (more popular) Perl testing libraries, but there just weren't enough tuits lying around to make all the changes throughout the perl-framework. the argument at the time was that this was OK(tm) because the only thing affected was the debugging output, not the actual comparison. I'll take the blame for that brain fart too, but again a severe lack of free time got in the way of doing things a bit better. however, those of us that are reasonably active here were aware of this, uh, issue and were changing test files as we touched them for other reasons. so yeah, it sucks, continues to suck, and I'm sorry. I'll buy you a beer or two at apachecon to make up for it :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test Makefile.PL Changes
+sub clean_files {
+return [
+qw(lib/Apache/TestConfigData.pm
+ .mypacklist
+ t/TEST
+ ),
+ ];
+}
[EMAIL PROTECTED] mod_perl-2.0]$ perl Makefile.PL
MP_APXS=/usr/local/apache2/bin/apxs
Reading Makefile.PL args from @ARGV
MP_APXS = /usr/local/apache2/bin/apxs
Configuring Apache/2.0.49 mod_perl/1.99_17-dev Perl/v5.8.3
Subroutine clean_files redefined at ./Makefile.PL line 56.
--Geoff
Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. we already have APACHE_TEST_EXTRA_ARGS which will do this :) --Geoff
Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
Geoffrey Young wrote: When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. we already have APACHE_TEST_EXTRA_ARGS which will do this :) rats... sorry, APACHE_TEST_EXTRA_ARGS is for A-T, not invoking httpd. eesh :) while it doesn't solve problems for anyone running A-T for the first time (such as when installing via CPAN), +1 to supporting this option as well, just in case people find it useful. time to shutdown the computer for the weekend... --Geoff
Re: -one-process configuration option
Stas Bekman wrote: Geoffrey Young wrote: hi all... I've found it necessary to toggle single server mode when using Apache-Test, specifically for getting Devel::Cover to work with mod_perl 1.0 nicely. so, I'd like to add an option for switching back to single server mode on demand for a normal run. +1, with the style fix below: done. thanks :) --Geoff
Re: [Patch] Caching apxs queries
+ Before: Files=218, Tests=2512, 1032 wallclock secs (594.94 cusr + 431.33 csys = 1026.27 CPU) + After: Files=218, Tests=2512, 246 wallclock secs (196.69 cusr + 33.55 csys = 230.24 CPU) gozer++, +1 whee! gozer++ --Geoff
Re: run_tests and test_clean
Are you sure that there will be no side effects? I'm pretty sure. it's not like test_clean won't be called under normal 'make test' circumstances, it's just that now there would be a way around it if the user thinks it is beneficial. If yes, then +1 ok, cool. if things blow up then I'll revert it, but I'm not seeing any problems on my end. Why not just run t/TEST directly instead of using make? I never use make when developing tests. So it was never an issue for me. t/TEST works fine for smallish things, but make is nice for automatically computing and including library directories spread out all over the place. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
[EMAIL PROTECTED] wrote:
geoff 2004/09/15 16:55:31
Modified:perl-framework/Apache-Test Changes
perl-framework/Apache-Test/lib/Apache TestMM.pm
Log:
run_tests make target no longer invokes t/TEST -clean, making it
possible to save a few development cycles when a full cleanup is
not required between runs.
TestMB.pm probably should be updated to be consistent as well.
David, I think the attached patch is right but I'll leave TestMB entirely up
to you.
--Geoff
? mb.patch
? quick.patch
Index: lib/Apache/TestMB.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestMB.pm,v
retrieving revision 1.7
diff -u -r1.7 TestMB.pm
--- lib/Apache/TestMB.pm 5 Sep 2004 00:11:30 - 1.7
+++ lib/Apache/TestMB.pm 15 Sep 2004 23:56:48 -
@@ -53,7 +53,6 @@
sub ACTION_run_tests {
my $self = shift;
-$self-depends_on('test_clean');
# XXX I'd love to do this without t/TEST.
$self-do_system($self-perl, $self-_bliblib,
$self-localize_file_path($self-apache_test_script),
@@ -71,8 +70,8 @@
sub ACTION_test {
my $self = shift;
$self-depends_on('code');
-$self-depends_on('run_tests');
$self-depends_on('test_clean');
+$self-depends_on('run_tests');
}
sub _cmodules {
run_tests and test_clean
hi all... in TestMM.pm we have this: test_clean : ... run_tests : test_clean ... test :: pure_all run_tests test_clean in a test suite with *lots* of files, test_clean takes forever. however, I experience has shown me that test_clean is only really required when you make changes to a configuration file or have autogenerated files you want to regenerate, making it a waste common development circumstances where a single test file is run over and over again. I'd like to suggest that test_clean _not_ be a prerequisite for run_tests, but instead shuffle the 'test' target around a bit. with the attached patch, you can save *lots* of cycles by doing something similar to the following: $ make test TEST_FILES=t/foo.t $ make run_tests TEST_FILES=t/foo.t $ make run_tests TEST_FILES=t/foo.t ... in my current situation, the first (with t/TEST -clean) runs in 45 seconds, while the second (and subsequent) iteration runs in 29 seconds. definitely a plus for me :) --Geoff Index: lib/Apache/TestMM.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestMM.pm,v retrieving revision 1.37 diff -u -r1.37 TestMM.pm --- lib/Apache/TestMM.pm 5 Sep 2004 00:11:30 - 1.37 +++ lib/Apache/TestMM.pm 15 Sep 2004 18:45:27 - @@ -65,12 +65,12 @@ $(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ t/TEST $(APACHE_TEST_EXTRA_ARGS) -clean -run_tests : test_clean +run_tests : $(PASSENV) \ $(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ t/TEST $(APACHE_TEST_EXTRA_ARGS) -bugreport -verbose=$(TEST_VERBOSE) $(TEST_FILES) -test :: pure_all run_tests test_clean +test :: pure_all test_clean run_tests cmodules: cd c-modules $(MAKE) all
Re: shell_ready function
Joe Orton wrote:
Does the quote escaping really work in this function?
hmm, it doesn't look like it does. I think this was part of some work that
stas and ken were doing, though, and IIRC it was some win32 command line
thing. but I could be wrong.
It confuses emacs
font-lock mode which doesn't see a closing quote so thinks the rest of
the file is part of the string. This fixes at least the latter:
-$arg =~ s//\/g;
+$arg =~ s//\\/g;
that looks better, but I'm not sure it's right either - if the input is
already escaped then you've (both) over-quoted (if the first worked at all,
that is :) so, you look to be fine here if pre-quoted input is forbidden or
not expected, but not so if it's already quoted, in which case something
like this is better:
$arg =~ s!([^\\])!$1\\!g;
the attached script runs through a few different regex and input
combinations for visual inspection. hopefully that will help sort this
issue out a bit (or the original author will clear things up ;)
--Geoff
#!/usr/bin/perl
foreach my $data (DATA) {
chomp $data;
print 'old: ', shell_ready_old($data), \n;
print 'joe: ', shell_ready_joe($data), \n;
print 'geoff: ', shell_ready_geoff($data), \n;
print '-' x 30, \n;
}
sub shell_ready_old {
my $arg = shift;
$arg =~ s//\/g;
return qq[$arg];
}
sub shell_ready_joe {
my $arg = shift;
$arg =~ s//\\/g;
return qq[$arg];
}
sub shell_ready_geoff {
my $arg = shift;
$arg =~ s!([^\\])!$1\\!g;
return qq[$arg];
}
__DATA__
one fish two fish
red \fish\ blue \fish\
this one has a little star
this one has a \little car
say, \what \a \lot of fish there are
Re: shell_ready function
and here is the optimized version of Geoff's one:
sub shell_ready_stas {
my $arg = shift;
$arg =~ s!\\?!\\!g;
return qq[$arg];
}
:)
Benchmark: timing 100 iterations of geoff, stas...
geoff: 64 wallclock secs (56.35 usr + 0.10 sys = 56.45 CPU) @
17714.79/s (n=100)
stas: 43 wallclock secs (40.27 usr + 0.06 sys = 40.33 CPU) @
24795.44/s (n=100)
/me bows to the master
--Geoff
time for 1.13?
obviously the release candidate from last week (or was it the week before) has been cancelled due to some semi-major code revisions. are we in a position where we can think about rolling a new candidate? --Geoff
Re: failing httpd-test tests
Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. no problem, that's part of the process. Oh, yeah, I got it right away when trying to build mp2. Looking at it. I think I've a good workaround for now. Please try again with the current cvs. Still having a problem? nope, looks good. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm
Stas Bekman wrote: [EMAIL PROTECTED] wrote: stas2004/08/08 23:19:16 Modified:perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm Log: another round of fixes of fixes We are definitely not ready for the planned release. My recent attempts to fix a fatal configuration bug affecting end users, have unstabilized things, as I have shuffled some of the execution sequences, and w/o tests I couldn't do through testing. So I discover problem as I deply A-T in various context. I hope it'll be back to stable soonish. yeah, we discussed this semi-privately - we're bagging the proposed release of A-T 1.13 and will re-roll a 1.13 candidate in a bit when we're all done tinkering. funny how activity seems to come in flurries :) --Geoff
Re: failing httpd-test tests
Stas Bekman wrote: Do you also get these tests failing with the current httpd-2.0? Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/limits.t 102 20.00% 7 9 I only get this one on a clean checkout (before your changes - no time to test now :) --Geoff
Test::More server support redux
hi all...
michael schwern is very close to releasing Test::More 0.49, which is the
first version of Test::More that we can use as the server-backend for
Apache::Test.
I would like to integrate the Test::More foo into A-T as soon as 0.49 comes
out. so, if you are interested in Test::More support and have some free
tuits, I would appreciate some feedback on the work I have thus far.
the first thing to do is download the latest Test::More
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Test-Simple-0.48_02.tar.gz
which schwern said is really the release candidate for 0.49.
then, apply the attached patch and let me know how the tests turn out.
really, I know that the Apache/Test.pm patch works, so if you have test
failures it is more likely due to the test setup itself - I didn't want to
move from Apache::TestRun to Apache::TestRunPerl so I needed to set up some
of the mod_perl specific things myself. hopefully I got most of them right :)
the tests pass successfully for me for apache 1.3 and 2.0, both with and
without mod_perl installed (well, they don't run with without mod_perl but
they don't implode either ;)
anyway, as I've mentioned before, I've been using Test::More as the backend
for a while now on a corporate project and it rocks, so I'm excited to port
it over when 0.49 is official. feedback welcome.
--Geoff
Index: lib/Apache/Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.90
diff -u -r1.90 Test.pm
--- lib/Apache/Test.pm 4 Aug 2004 19:07:06 - 1.90
+++ lib/Apache/Test.pm 5 Aug 2004 14:20:06 -
@@ -17,7 +17,6 @@
use strict;
use warnings FATAL = 'all';
-use Test qw(ok skip);
use Exporter ();
use Config;
use Apache::TestConfig ();
@@ -52,6 +51,48 @@
}
my $Config;
+my $real_plan;
+my @testmore;
+
+sub import {
+my $class = shift;
+
+# once Test::More always Test::More until plan() is called
+if (($_[0] and $_[0] =~ m/^-withtestmore/) || @testmore) {
+# special hoops for Test::More support
+
+$real_plan = eval {
+
+require Test::More;
+
+no warnings qw(numeric);
+Test::Builder-VERSION('0.18_01');
+
+# required for Test::More::import() and Apache::Test::plan()
+# if we don't do this, Test::More exports plan() anyway
+# and we get collisions. go figure.
+@testmore = (import = [qw(!plan)]);
+
+Test::More-import(@testmore);
+
+\Test::More::plan;
+} or die -withtestmore error: $@;
+
+# clean up arguments to export_to_level
+shift;
+@EXPORT = (@test_more_exports, @Test::More::EXPORT);
+}
+else {
+# the default - Test.pm support
+
+require Test;
+Test-import(qw(ok skip));
+@testmore = (); # reset, just in case.
+$real_plan = \Test::plan;
+}
+
+$class-export_to_level(1, undef, @_ ? @_ : @EXPORT);
+}
sub config {
$Config ||= Apache::TestConfig-thaw;
@@ -67,7 +108,7 @@
if (%SubTests and not $SubTests{ $Test::ntest }) {
for my $n (1..$nok) {
-skip skipping this subtest, 0;
+skip(skipping this subtest, 0);
}
return;
}
@@ -84,10 +125,26 @@
#so Perl's Test.pm can be run inside mod_perl
sub test_pm_refresh {
-$Test::TESTOUT = \*STDOUT;
-$Test::planned = 0;
-$Test::ntest = 1;
-%Test::todo = ();
+if (@testmore) {
+
+Test::Builder-reset;
+
+Test::Builder-output(\*STDOUT);
+Test::Builder-todo_output(\*STDOUT);
+
+# this is STDOUT because Test::More seems to put
+# most of the stuff we want on STDERR, so it ends
+# up in the error_log instead of where the user can
+# see it. consider leaving it alone based on
+# later user reports.
+Test::Builder-failure_output(\*STDOUT);
+}
+else {
+$Test::TESTOUT = \*STDOUT;
+$Test::planned = 0;
+$Test::ntest = 1;
+%Test::todo = ();
+}
}
sub init_test_pm {
@@ -177,7 +234,7 @@
}
@SkipReasons = (); # reset
-Test::plan(@_);
+$real_plan-(@_, @testmore);
# add to Test.pm verbose output
print # Using Apache/Test.pm version $VERSION\n;
@@ -826,6 +883,41 @@
plan tests = 1; # Test::More::plan()
ok ('yes', 'testing ok'); # Test::More::ok()
+
+Now, while this works fine for standard client-side tests
+(such as Ct/basic.t), the more advanced features of IApache::Test
+require using ITest::More as the sole driver behind the scenes.
+
+Should you choose to use ITest::More as the backend for
+server-based tests (such as Ct/response/TestMe/basic.pm) you will
+need to use the C-withtestmore action tag:
+
+use Apache::Test qw(-withtestmore);
+
+sub handler {
+
+my $r = shift;
+
+plan $r, tests = 1; #
Re: Test::More server support redux
+Note that ITest::Builder 0.18_01, available in ITest::Simple
+version 0.48_01 on CPAN, is required to use this feature.
drop that, as 2 copies of the same thing in different places will go out
of sync at some point. check on the code level should be sufficient.
instead the error message could say where to find the required version.
well, maybe it's not clear - colloquially most people I've talked to refer
to Test::More. but Test::More isn't a distribution, it's part of
Test::Simple (as is Test::Builder).
anyway, I'll know more about the module versions when Test::Simple 0.49 is
released - if all the versions of the underlying packages are correct I'll
just require 0.49 and be done with it.
-my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test
lib);
-my $cmd = qq[$^X -Mlib=$lib $file];
+# so we can find Apache/Test.pm from both the perl-framework
+# and Apache-Test. note that IS_APACHE_TEST_BUILD returns
+# true for the perl-framework as well
+my $lib = join ':',
+catfile(Apache::Test::vars('top_dir'), qw(Apache-Test lib)),
+catfile(Apache::Test::vars('top_dir'), 'lib');
+my $cmd = qq[PERL5LIB=$lib $^X $file];
why this change? is there anything wrong with -Mlib?
yes. the problem is that currently all.t does not get run properly from
Apache-Test/. the current code adds makes @INC look like
perl-framework/Apache-Test/Apache-Test/lib when running from the A-T directory.
PERL5LIB will be
ignored under -T -- code will be broken.
yes, but it shouldn't be a problem, since $lib is only important if A-T
can't be found, which is presumably only when running from the
perl-framework/ or Apache-Test/ directories. which is why I have my comment
that IS_APACHE_TEST_BUILD is insufficient to determine whether it is a real
A-T build or someone running from the perl-framework.
+
+IfModule mod_perl.c
+ IfDefine APACHE2
+PerlModule Apache2
+ /IfDefine
why not put the stuff below into extra.last.conf.in. Apache2 will be
loaded by then. It's better not to mess with Apache2 before times.
because unless I use TestRunPerl (over TestRun) nothing mod_perl will be set
up, including Apache2. so it's not a matter of timing, but rather if
Apache2 is loaded at all.
+use Apache::TestRequest 'GET_BODY_ASSERT';
+print GET_BODY_ASSERT /TestMore__testmorepm;
hmm, what are you trying to achieve with repeating two tests twice? what
if you don't hit the same interpreter if that's what you are after?
the reason they are run twice (and in alternating Test.pm and Test::More
order) is that when I first coded it there was a bug in that Test::More
would never release itself from the tests due to some global variables.
0.49 addresses this with an official API for persistent environments, which
I can now call (and is why we can't use any earlier versions).
so, yes, I suppose it is an interpreter issue.
It's probably better to use 1 test and run the same_interprter framework?
well, the multiple test calls are to make sure that users can intermix
Test.pm and Test::More plans on the server, so I clearly want multiple tests
and not just one if I'm going to mimic user activity. but I'll look into
using same_interpreter to make sure that threaded mpms work properly as well.
+ 0;
What's 0? Should it be Apache::OK?
sure.
--Geoff
libwww-perl 5.800 failures
hi all...
I just upgraded to libwww-perl 5.800 and found that a few POST tests started
failing where they didn't before, namely t/apache/post.t and t/http11/post.t.
I think the underlying problem is this change in HTTP::Message:
HTTP::Message will now allow an external 'content_ref'
to be set. This can for instance be used to let HTTP::Request
objects pick up content data from some scalar variable without
having to copy it.
which I think means that you can no longer set
my $content = sub {...};
$request-content($content);
as we do in Apache::TestCommonPost::lwp_do(). I didn't write that code and
am having a hard time following it, but I assume that the coderef assumed
LWP would call the coderef until the C-L was fulfilled, which seems to no
longer be true.
so, if anyone is familiar with how TestCommonPost works and what it is
testing, it would be really helpful if you could explain why the buffering
in lwp_do is required and why we can't just set $response-content to the
C-L size up front.
--Geoff
[RELEASE CANDIDATE] Apache-Test-1.13
a release candidate for Apache-Test 1.13 is now available. http://perl.apache.org/~geoff/Apache-Test-1.13-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. --Geoff Changes since 1.12: the have() function was removed entirely - use need() instead. [Geoffrey Young] add need() and need_* variant functions (need_module(), need_apache(), etc) for use specifically with plan() to decide whether or not a test should run. have_* variants (have_module(), have_apache(), etc) are now specifically for use outside of plan(), although they can continue to be used within plan() without fear of current tests breaking. [Geoffrey Young] add need_php() and have_php() which will return true when either mod_php4 or mod_php5 are available, providing functionality similar to need_cgi() and have_cgi(). [Geoffrey Young] Add APACHE_TEST_EXTRA_ARGS make variable to all invocations to t/TEST to allow passing extra arguments from the command line. [Gozer] When APACHE_TEST_NO_STICKY_PREFERENCES=1 is used don't even try to interactively configure the server, as we don't save any config it was entering an infinite loop. [Stas] If a directory t/lib exists from where the tests are run, adjust @INC so that this directory is added when running the tests, both within t/TEST and within t/conf/modperl_inc.pl. This allows inclusion of modules specific to the tests that aren't intended to be installed. [Stas, Randy] make a special case for threaded mpm configuration, to ensure that unless maxclients was specified, MaxClients will be exactly twice bigger than ThreadsPerChild (minclients), since if we don't do that, Apache will reduce MaxClients to the same value as ThreadsPerChild. [Stas] Renamed generate_test_script() to generate_script() in Apache::TestMB to match the naming convention used in Apache::TestMM and elsewhere. [David] Apache::TestMB now only prints the Generating test running script message if verbosity is enabled (e.g., by passing --verbose when executing Build.PL). [David] Fixed the requests_redirectable parameter to Apache::TestRequest::user_agent() so that it works as docmented when passed a negative value. [Boris Zentner] Documented support for passing an array reference to the requests_redirectable parameter to Apache::TestRequest::user_agent() to be passed to LWP::UserAgent if LWP ist installed. [David]
Re: Infinite looping in self-configuration mode (was Re: [RELEASE CANDIDATE] Apache-Test-1.06)
OK, please let us know when and if you see it again. I see that there were quite a few changes since the last A-T release, any volunteers to wear the Release Manager cap and get a new version out? I'll do it, once the need_* functions have been implemented (which I'll do as well :) --Geoff
[PATCH] new need functions
hi all
ok, attached is a patch that implements the new need variants and alters the
old have variants. basically, all I did was a global rename of have to
need, then implement the have routines in terms of need with the AutoLoader.
I thought this made a bit more sense than redefining all of those
subroutines again when the only difference was simply not populating
@SkipReasons.
the mod_perl test suite continues to run, as does the perl-framework, so
nothing (that I can see at least) should be broken.
anyway, comments welcome, as well as documentation - I couldn't decide where
to add the have stuff so I just didn't do anything.
--Geoff
Index: lib/Apache/Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.87
diff -u -r1.87 Test.pm
--- lib/Apache/Test.pm 31 Jul 2004 01:35:25 - 1.87
+++ lib/Apache/Test.pm 2 Aug 2004 15:46:28 -
@@ -22,7 +22,8 @@
use Config;
use Apache::TestConfig ();
-use vars qw(@ISA @EXPORT %EXPORT_TAGS $VERSION %SubTests @SkipReasons);
+use vars qw(@ISA @EXPORT %EXPORT_TAGS $VERSION %SubTests @SkipReasons
+$AUTOLOAD);
@ISA = qw(Exporter);
@EXPORT = qw(ok skip sok plan have have_lwp have_http11
@@ -30,7 +31,12 @@
have_min_apache_version have_apache_version have_perl
have_min_perl_version have_min_module_version
have_threads under_construction skip_reason have_apache_mpm
- have_php);
+ have_php
+ need need_lwp need_http11 need_cgi need_access need_auth
+ need_module need_apache need_min_apache_version
+ need_apache_version need_perl need_min_perl_version
+ need_min_module_version need_threads need_apache_mpm
+ need_php);
# everything but ok(), skip(), and plan() - Test::More provides these
my @test_more_exports = grep { ! /^(ok|skip|plan)$/ } @EXPORT;
@@ -104,7 +110,7 @@
$r-content_type('text/plain');
}
-sub have_http11 {
+sub need_http11 {
require Apache::TestRequest;
if (Apache::TestRequest::install_http11()) {
return 1;
@@ -116,12 +122,12 @@
}
}
-sub have_ssl {
+sub need_ssl {
my $vars = vars();
-have_module([$vars-{ssl_module_name}, 'Net::SSL']);
+need_module([$vars-{ssl_module_name}, 'Net::SSL']);
}
-sub have_lwp {
+sub need_lwp {
require Apache::TestRequest;
if (Apache::TestRequest::has_lwp()) {
return 1;
@@ -150,7 +156,7 @@
}
elsif ($ref eq 'ARRAY') {
#plan tests $n, [qw(php4 rewrite)];
-$meets_condition = have_module($condition);
+$meets_condition = need_module($condition);
}
else {
die don't know how to handle a condition of type $ref;
@@ -178,29 +184,29 @@
print # Using Apache/Test.pm version $VERSION\n;
}
-sub have {
-my $have_all = 1;
+sub need {
+my $need_all = 1;
for my $cond (@_) {
if (ref $cond eq 'HASH') {
while (my($reason, $value) = each %$cond) {
$value = $value-() if ref $value eq 'CODE';
next if $value;
push @SkipReasons, $reason;
-$have_all = 0;
+$need_all = 0;
}
}
elsif ($cond =~ /^(0|1)$/) {
-$have_all = 0 if $cond == 0;
+$need_all = 0 if $cond == 0;
}
else {
-$have_all = 0 unless have_module($cond);
+$need_all = 0 unless need_module($cond);
}
}
-return $have_all;
+return $need_all;
}
-sub have_module {
+sub need_module {
my $cfg = config();
my @modules = ref($_[0]) ? @{ $_[0] } : @_;
@@ -234,7 +240,7 @@
}
}
-sub have_min_perl_version {
+sub need_min_perl_version {
my $version = shift;
return 1 if $] = $version;
@@ -244,11 +250,11 @@
}
# currently supports only perl modules
-sub have_min_module_version {
+sub need_min_module_version {
my($module, $version) = @_;
-# have_module requires the perl module
-return 0 unless have_module($module);
+# need_module requires the perl module
+return 0 unless need_module($module);
return 1 if eval { $module-VERSION($version) };
@@ -256,23 +262,23 @@
return 0;
}
-sub have_cgi {
-have_module('cgi') || have_module('cgid');
+sub need_cgi {
+need_module('cgi') || need_module('cgid');
}
-sub have_php {
-have_module('php4') || have_module('php5');
+sub need_php {
+need_module('php4') || need_module('php5');
}
-sub have_access {
-have_module('access') || have_module('authz_host');
+sub need_access {
+need_module('access') || need_module('authz_host');
}
-sub have_auth {
-have_module('auth') || have_module('auth_basic');
+sub need_auth {
+need_module('auth') || need_module('auth_basic');
}
-sub have_apache {
Re: [PATCH] new need functions
I'd suggest to simply explain that there are have_ and need_ functions
at the beginning of that section that explains need_* ones. And one
should use need_* inside plan(), because of the skip messages. Otherwise
use have_*.
ok, done.
Please don't commit w/o the docs. Once it's committed, the docs are most
likely will be forgotten.
of course, no reminder necessary :)
You don't want to remember to update two places when you add new
functions. So there should be a need* functions array and when you
populate the @EXPORT list you generate the have* list. Also there should
be no have() function, but only need(). The rest map need_* = have_*.
good idea, done.
Next you can use that have* list to generate the actual functions on the
fly, similar to the generation of the subs similar to log levels subs in
Apache::TestTrace. So you don't really need AUTOLOAD. It'll take the
same amount of code w/o AUTOLOAD.
except that the autoload code is already written :)
+sub AUTOLOAD {
+
+use vars qw($AUTOLOAD @SkipReasons);
haven't you declared the two at the top of Test.pm already?
sorry, leftover debugging foo.
why not just:
local @SkipReasons;
return $cv-(@_);
yeah, that's better.
new patch attached.
--Geoff
Index: lib/Apache/Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.87
diff -u -r1.87 Test.pm
--- lib/Apache/Test.pm 31 Jul 2004 01:35:25 - 1.87
+++ lib/Apache/Test.pm 2 Aug 2004 18:08:44 -
@@ -22,15 +22,19 @@
use Config;
use Apache::TestConfig ();
-use vars qw(@ISA @EXPORT %EXPORT_TAGS $VERSION %SubTests @SkipReasons);
+use vars qw(@ISA @EXPORT %EXPORT_TAGS $VERSION %SubTests @SkipReasons
+$AUTOLOAD);
+
+my @need = qw(need_lwp need_http11 need_cgi need_access need_auth
+ need_module need_apache need_min_apache_version
+ need_apache_version need_perl need_min_perl_version
+ need_min_module_version need_threads need_apache_mpm
+ need_php);
+
+my @have = map { (my $need = $_) =~ s/need/have/; $need } @need;
@ISA = qw(Exporter);
[EMAIL PROTECTED] = qw(ok skip sok plan have have_lwp have_http11
- have_cgi have_access have_auth have_module have_apache
- have_min_apache_version have_apache_version have_perl
- have_min_perl_version have_min_module_version
- have_threads under_construction skip_reason have_apache_mpm
- have_php);
[EMAIL PROTECTED] = (qw(ok skip sok plan skip_reason under_construction need), @need, @have);
# everything but ok(), skip(), and plan() - Test::More provides these
my @test_more_exports = grep { ! /^(ok|skip|plan)$/ } @EXPORT;
@@ -104,7 +108,7 @@
$r-content_type('text/plain');
}
-sub have_http11 {
+sub need_http11 {
require Apache::TestRequest;
if (Apache::TestRequest::install_http11()) {
return 1;
@@ -116,12 +120,12 @@
}
}
-sub have_ssl {
+sub need_ssl {
my $vars = vars();
-have_module([$vars-{ssl_module_name}, 'Net::SSL']);
+need_module([$vars-{ssl_module_name}, 'Net::SSL']);
}
-sub have_lwp {
+sub need_lwp {
require Apache::TestRequest;
if (Apache::TestRequest::has_lwp()) {
return 1;
@@ -150,7 +154,7 @@
}
elsif ($ref eq 'ARRAY') {
#plan tests $n, [qw(php4 rewrite)];
-$meets_condition = have_module($condition);
+$meets_condition = need_module($condition);
}
else {
die don't know how to handle a condition of type $ref;
@@ -178,29 +182,29 @@
print # Using Apache/Test.pm version $VERSION\n;
}
-sub have {
-my $have_all = 1;
+sub need {
+my $need_all = 1;
for my $cond (@_) {
if (ref $cond eq 'HASH') {
while (my($reason, $value) = each %$cond) {
$value = $value-() if ref $value eq 'CODE';
next if $value;
push @SkipReasons, $reason;
-$have_all = 0;
+$need_all = 0;
}
}
elsif ($cond =~ /^(0|1)$/) {
-$have_all = 0 if $cond == 0;
+$need_all = 0 if $cond == 0;
}
else {
-$have_all = 0 unless have_module($cond);
+$need_all = 0 unless need_module($cond);
}
}
-return $have_all;
+return $need_all;
}
-sub have_module {
+sub need_module {
my $cfg = config();
my @modules = ref($_[0]) ? @{ $_[0] } : @_;
@@ -234,7 +238,7 @@
}
}
-sub have_min_perl_version {
+sub need_min_perl_version {
my $version = shift;
return 1 if $] = $version;
@@ -244,11 +248,11 @@
}
# currently supports only perl modules
-sub have_min_module_version {
+sub need_min_module_version {
my($module, $version) = @_;
-# have_module requires the perl
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
David Wheeler wrote: On Jul 31, 2004, at 5:04 PM, Stas Bekman wrote: I guess losing the skip message by making need_ functions that replace the existing have_ functions is okay. It's most important that tests continue to pass... They will. Then I say we go with need. I kind of favor this as well - it's really no big deal that have functions will all of a sudden stop printing a skip message, and in doing so it will encourage users that care to upgrade to the new function. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
Using have_ macros for non-plan() usage should be avoided, since it
populates the SKIP messages array and if later the test is skipped, for
a different reason it'll misleadingly tell the user that LWP was also a
requirement for that test (which quite possibly could be what we want).
We need to fix that in general (since this issue is recurrent) and have
a better way to handle requirements check+skip and only requirements
check. Ideas?
have_foo('bar', 1); # don't populate @SkipReason
or
check_foo('bar');# same as have_foo but don't populate @SkipReason
or a combination of both (where check_foo() is a wrapper around
have_foo($a,1) and we keep the interface undocumented).
?
--Geoff
Re: [Patch] add TEST_EXTRA_ARGS to allow passing arguments to t/TEST thru make invocation
Philippe M. Chiasson wrote: Geoffrey Young wrote: ping :) Must have fell off my radar. How is the following patch ? +1 --Geoff
Re: [Patch] add TEST_EXTRA_ARGS to allow passing arguments to t/TEST thru make invocation
ping :) --Geoff Stas Bekman wrote: Geoffrey Young wrote: I'm not sure about the name choice. $(TEST_VERBOSE) and $(TEST_FILES) are the same as other Test packages use. Do they have $TEST_EXTRA_ARGS too? Otherwise we may better use some name specific to Apache-Test? MakeMaker looks to support only three: TEST_VERBOSE, TEST_FILE(S), and TESTDB_SW. so how about APACHE_TEST_EXTRA_ARGS? it's verbose but it shouldn't be too bad and it beats making tons of extra targets. +1
Re: cvs commit: httpd-test/perl-framework/t/apache errordoc.t
This makes the test fail against 2.0.50, but it's just a lack-of-feature
right, so OK if I half-revert this?
the last time I asked about this, the consensus was that the perl-framework
is expected to be for developer use only, expected to run (and in some cases
compile) successfully only on current CVS 1.3/2.0/2.1.
IIRC there are some things that will definitely fail in older httpd releases
(some mod_include stuff comes to mind) and we haven't coded around
have_min_apache_version for exactly this reason.
--- t/apache/errordoc.t 12 Jul 2004 17:03:49 - 1.3
+++ t/apache/errordoc.t 16 Jul 2004 12:16:25 -
@@ -59,7 +59,8 @@
'/redefine/notfound.html code');
# 1.3 requires quotes for hard-coded messages
-my $expected = have_apache(2) ? qr/Not Found/ :
+my $expected = have_min_apache_version('2.0.51') ? qr/Not Found/ :
+ have_apache(2)? 'default' :
qr/Additionally, a 500/;
ok t_cmp($content,
I'm not necessarily against this, except that this isn't the only test that
will fail if you use something less than cvs.
so, perhaps now is a good time to reevaluate the prior consensus. is the
perl-framework a developer tool or should we be accounting for httpd changes
between releases?
I just ran against 2.0.46 (which is the oldest httpd the mod_perl currently
supports, so I keep one laying around :) and the only failures are from
errordoc.t and include.t. while errordoc.t is easy enough to fix with your
patch, mod_include may be a bit more difficult, since IIRC the changes
spanned several httpd releases.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm
And may be this is a good idea for the A-T skeleton as well :) indeed :) actually, the bug reporting skeleton used t/My/Handler.pm, and I'll certainly change that to t/lib not. the A-T module skeleton actually starts with no supporting modules, since you would want to install the module you're testing. but maybe I'll come up with something anyway :) --Geoff
Re: A::T :withtestmore
I changed it to bugpm.pm (and changed the package name) and it worked fine. Actually, changing it to bug_tm.pm works. I had forgotten to change the package name when I retested :(. So hyphens in response tests are a bad thing? the limitation here is that perl package namespaces cannot contain hyphens, which is not specifically mentioned but can be inferred from perlvar.pod, Technical Note on the Syntax of Variable Names. --Geoff
Re: A::T :withtestmore
[Sun Jul 11 16:31:59 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) Warning: Use of require without parentheses is ambiguous at (eval 12) line 1. [Sun Jul 11 16:32:01 2004] [error] Undefined subroutine TestApache::My::Bug::bug-tm::handler called.\n [Sun Jul 11 16:32:01 2004] [info] removed PID file /home/william/perl/bug-reporting-skeleton-mp1/t/logs/httpd.pid (pid=2537) Do you see this error when you run my package? yup. This makes me think that there may be a problem in the bug testing framework itself when used in conjunction with the -testmore action. I don't think so :) I don't see a require statement in Bug.pm so am at a loss to say why this would be failing. I tried changing the name of bug-tm.pm to bug_tm.pm in case the hypen was a problem; it didn't help. Any other ideas? I changed it to bugpm.pm (and changed the package name) and it worked fine. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMB.pm
[EMAIL PROTECTED] wrote: theory 2004/07/09 13:01:26 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestMB.pm Log: Be verbose in TestMB when verbosity is called for, but not otherwise. can somebody please subscribe david to test-cvs so I don't need to moderate his entries anymore? --Geoff
Re: A::T :withtestmore
The problem appears to be due to headers not being sent when using
Test::More. I found the code in Apache::Test which initializes a handler
when `plan $r, tests = 10` is called.
you can't use Test::More on the server side (that is, from a handler, such
as you have here). at least not with the current Apache-Test.
to do that, you need to apply the attached patch - it may have some fuzz due
to a change that I just implemented this week, but I have been using it for
a few months now and haven't had any problems (once I figured out all the
issues, that is).
so, apply the patch and read the docs in the patch and you should be good to
go. if you have trouble getting it to apply I'll whip up a current one next
week.
oh, and keep in mind that until Test::More goes official with the features
in the (required) development version this will _not_ get integrated into
Apache-Test. that's not to say I haven't found it stable, but rather that
we can't integrate features into our stable software that depend on an
external development API.
--Geoff
Index: Apache/Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.83
diff -u -r1.83 Test.pm
--- Apache/Test.pm 1 Jun 2004 18:21:11 - 1.83
+++ Apache/Test.pm 2 Jun 2004 00:49:20 -
@@ -17,7 +17,6 @@
use strict;
use warnings FATAL = 'all';
-use Test qw(ok skip);
use Exporter ();
use Config;
use Apache::TestConfig ();
@@ -46,6 +45,48 @@
}
my $Config;
+my $real_plan;
+my @testmore;
+
+sub import {
+my $class = shift;
+
+# once Test::More always Test::More until plan() is called
+if (($_[0] and $_[0] =~ m/^-withtestmore/) || @testmore) {
+# special hoops for Test::More support
+
+$real_plan = eval {
+
+require Test::More;
+
+no warnings qw(numeric);
+Test::Builder-VERSION('0.18_01');
+
+# required for Test::More::import() and Apache::Test::plan()
+# if we don't do this, Test::More exports plan() anyway
+# and we get collisions. go figure.
+@testmore = (import = [qw(!plan)]);
+
+Test::More-import(@testmore);
+
+\Test::More::plan;
+} or die -withtestmore error: $@;
+
+# clean up arguments to export_to_level
+shift;
+@EXPORT = (@test_more_exports, @Test::More::EXPORT);
+}
+else {
+# the default - Test.pm support
+
+require Test;
+Test-import(qw(ok skip));
+@testmore = (); # reset, just in case.
+$real_plan = \Test::plan;
+}
+
+$class-export_to_level(1, undef, @_ ? @_ : @EXPORT);
+}
sub config {
$Config ||= Apache::TestConfig-thaw;
@@ -61,7 +102,7 @@
if (%SubTests and not $SubTests{ $Test::ntest }) {
for my $n (1..$nok) {
-skip skipping this subtest, 0;
+skip(skipping this subtest, 0);
}
return;
}
@@ -78,10 +119,26 @@
#so Perl's Test.pm can be run inside mod_perl
sub test_pm_refresh {
-$Test::TESTOUT = \*STDOUT;
-$Test::planned = 0;
-$Test::ntest = 1;
-%Test::todo = ();
+if (@testmore) {
+
+Test::Builder-reset;
+
+Test::Builder-output(\*STDOUT);
+Test::Builder-todo_output(\*STDOUT);
+
+# this is STDOUT because Test::More seems to put
+# most of the stuff we want on STDERR, so it ends
+# up in the error_log instead of where the user can
+# see it. consider leaving it alone based on
+# later user reports.
+Test::Builder-failure_output(\*STDOUT);
+}
+else {
+$Test::TESTOUT = \*STDOUT;
+$Test::planned = 0;
+$Test::ntest = 1;
+%Test::todo = ();
+}
}
sub init_test_pm {
@@ -171,7 +228,7 @@
}
@SkipReasons = (); # reset
-Test::plan(@_);
+$real_plan-(@_, @testmore);
}
sub have {
@@ -783,6 +840,41 @@
plan tests = 1; # Test::More::plan()
ok ('yes', 'testing ok'); # Test::More::ok()
+
+Now, while this works fine for standard client-side tests
+(such as Ct/basic.t), the more advanced features of IApache::Test
+require using ITest::More as the sole driver behind the scenes.
+
+Should you choose to use ITest::More as the backend for
+server-based tests (such as Ct/response/TestMe/basic.pm) you will
+need to use the C-withtestmore action tag:
+
+use Apache::Test qw(-withtestmore);
+
+sub handler {
+
+my $r = shift;
+
+plan $r, tests = 1; # Test::More::plan() with
+ # Apache::Test features
+
+ok ('yes', 'testing ok'); # Test::More::ok()
+}
+
+C-withtestmore tells IApache::Test to use ITest::More
+instead of ITest.pm behind the scenes. Note that you are not
+required to Cuse Test::More yourself with the C-withtestmore
+option and that the Cuse Test::More tests
Re: A::T :withtestmore
William McKee wrote: Hi Geoff, Thanks for the info and the patch. I applied the patch without a problem and then went to install the developer release of T::M. Dost my eyes decieve me or does that say it was last updated on November 11, 2002? That's a long release cycle. indeed. At any rate, I installed the latest copy of T::M and read your directions in the patch. I couldn't get that patch to apply to current cvs. However, I'm still not getting the expected results. I suppose that could be the fuzz factor you mentioned but put together a new version of my test package in case you want to see if I'm just doing something stupid[1]. well, I get the same results, and I can't see offhand what you are doing wrong. but I started a tarball from scratch and was able to get it working with no problem at all. so, try this tarball http://perl.apache.org/~geoff/testmore-geoff.tar.gz which includes a new patch against current cvs. after installing Test-Simple-0.48_01 I get the expected output: server localhost.localdomain:8529 started t/geoff/foo1..1 # Using Apache/Test.pm version 1.13 ok 1 - use Apache::Constants; ok All tests successful. note (among other things) the lack of Test.pm verbose headers. I understand that you can't release this code until T::M is released but considering that T::M may be a bit longer baking, an additional caveat in the A::T pod would be useful in case T::M doesn't get released before the next release of A::T. I've attached a patch against the pristine version of 1.12. I thought I mentioned something like that someplace? oh, well... yeah, I'll look it over and make sure the docs are better. --Geoff
Re: Apache-Test module skeletons
Nice work, Geoff. May be they should live on CPAN, so one doesn't need to remember where to grab them from? e.g. create an empty Apache::Test::Skeleton::mod_perl(1|2) packages with versioning in those tars and upload to CPAN? that's an idea, but kind of a long name :) maybe just Apache::Test::Skeleton::MP1 or something. but yeah, I'll come up with a package and upload them to cpan soonish. --Geoff
Apache-Test module skeletons
hi all... the bug reporting skeleton has become so useful for me (and others) that I have created two new skeletons: http://perl.apache.org/~geoff/Apache-Test-skeleton-mp1.tar.gz http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz these are essentially the same as the bug reporting skeletons but geared toward new module development - a basic handler exists in lib/Apache/Handler.pm, references to bugs have been removed, etc. enjoy. --Geoff
[Fwd: [cpan #6800] Thread safety: work around perl sort bug]
Original Message
Subject: [cpan #6800] Thread safety: work around perl sort bug
Date: Wed, 30 Jun 2004 05:42:03 -0400 (EDT)
From: Guest via RT [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: undisclosed-recipients:;
This message about Apache-Test was sent to you by guest via rt.cpan.org
Full context and any attached attachments can be found at:
URL: https://rt.cpan.org/Ticket/Display.html?id=6800
perl-5.8.4. Apache-Test-1.12.
If thread safety is important to this module, suggest in TestServer.pm
you change:
my $by_port = sub { $vh-{$a}-{port} = $vh-{$b}-{port} };
for my $module (sort $by_port keys %$vh) {
to, something like:
for my $module (sort { $vh-{$a}-{port} = $vh-{$b}-{port} } keys %$vh) {
i.e. inline the sort sub to work around perl bug #30333
threads sort crashes with sort subroutine (but not with sort block).
/-\
[Fwd: FAIL Apache-Test-1.12 OpenBSD.i386-openbsd 3.5]
Original Message Subject: FAIL Apache-Test-1.12 OpenBSD.i386-openbsd 3.5 Date: Mon, 28 Jun 2004 22:51:54 +0200 (CEST) From: [EMAIL PROTECTED] (CPAN Tester. CPAN++ automate) To: cpan-testers@perl.org CC: [EMAIL PROTECTED] This distribution has been tested as part of the cpan-testers effort to test as many new uploads to CPAN as possible. See http://testers.cpan.org/ Please cc any replies to cpan-testers@perl.org to keep other test volunteers informed and to prevent any duplicate effort. -- This is an error report generated automatically by CPANPLUS, version 0.049. Below is the error stack during 'make test': /usr/local/perl-5.8.4/bin/perl -Iblib/arch -Iblib/lib t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= /usr/local/perl-5.8.4/bin/perl -Iblib/arch -Iblib/lib t/TEST -bugreport -verbose=0 We are now going to configure the Apache-Test framework. This configuration process needs to be done only once. First we need to know where the 'httpd' executable is located. If you have more than one Apache server is installed, make sure you supply the path to the one you are going to use for testing. You can always override this setting at run time via the '-httpd' option. For example: % t/TEST -httpd /path/to/alternative/httpd or via the environment variable APACHE_TEST_HTTPD. For example: % APACHE_TEST_HTTPD=/path/to/alternative/httpd t/TEST If for some reason you want to skip the test suite, type: skip Please provide a full path to 'httpd' executable or choose from the following options: [1] /usr/sbin/httpd [1] 1 Next we need to know where the 'apxs' script is located. This script provides a lot of information about the apache installation, and makes it easier to find things. However it's not available on all platforms, therefore it's optional. If you don't have it installed it's not a problem. Just press Enter. Notice that if you have Apache 2.x installed that script could be called as 'apxs2'. If you have more than one Apache server is installed, make sure you supply the path to the apxs script you are going to use for testing. You can always override this setting at run time via the '-apxs' option. For example: % t/TEST -apxs /path/to/alternative/apxs or via the environment variable APACHE_TEST_APXS. For example: % APACHE_TEST_APXS=/path/to/alternative/apxs t/TEST Please provide a full path to (optional) 'apxs' executable or choose from the following options: [1] /usr/sbin/apxs [1] 1 [warning] rerunning '/usr/local/perl-5.8.4/bin/perl /home/alian/.cpanplus/5.8.4/build/Apache-Test-1.12/t/TEST -bugreport -verbose=0' with new config opts /usr/sbin/httpd -d /home/alian/.cpanplus/5.8.4/build/Apache-Test-1.12/t -f /home/alian/.cpanplus/5.8.4/build/Apache-Test-1.12/t/conf/httpd.conf -D APACHE1 using Apache/1.3.29 waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.alianet:8529 started t/ping# Failed test 3 in t/ping.t at line 16 FAILED test 3 Failed 1/3 tests, 66.67% okay t/redirect# Failed test 4 in t/redirect.t at line 17 # Failed test 6 in t/redirect.t at line 23 FAILED tests 4, 6 Failed 2/6 tests, 66.67% okay t/request.# Failed test 1 in t/request.t at line 11 # Failed test 5 in t/request.t at line 16 # Failed test 8 in t/request.t at line 20 # Failed test 9 in t/request.t at line 22 FAILED tests 1, 5, 8-9 Failed 4/9 tests, 55.56% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ping.t31 33.33% 3 t/redirect.t62 33.33% 4 6 t/request.t 94 44.44% 1 5 8-9 Failed 3/3 test scripts, 0.00% okay. 7/18 subtests failed, 61.11% okay. [ error] error running tests (please examine t/logs/error_log) +-+ | To report problems please refer to the SUPPORT file | +-+ *** Error code 1 Stop in /home/alian/.cpanplus/5.8.4/build/Apache-Test-1.12 (line 831 of Makefile). Additional comments: -- Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=openbsd, osvers=3.5, archname=OpenBSD.i386-openbsd uname='openbsd neptune.alianet 3.5 generic#34 i386 ' config_args='-des -Dprefix=/usr/local/perl-5.8.4 [EMAIL PROTECTED]' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include'
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
Stas Bekman wrote: [EMAIL PROTECTED] wrote: stas2004/06/27 11:46:03 Modified:perl-framework/Apache-Test/lib/Apache TestReportPerl.pm perl-framework/Apache-Test Changes Log: Force projects that use Apache::TestReportPerl to implement report_to() if they use t/REPORT in their projects. ay, didn't realize the candidate is still out there and wasn't released. Sorry about that. Though these changes should be harmless :) that's ok - I have rerolled a new candidate with these changes incorporated for you to test ;) if all looks good to you I'll release. --Geoff
[ANNOUNCE] Apache-Test-1.12
The URL http://perl.apache.org/~geoff/Apache-Test-1.12.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.12.tar.gz size: 120719 bytes md5: 1db40538fd85be3544de8614552c385d --Geoff Changes since 1.11: Force projects that use Apache::TestReportPerl to implement report_to() if they use t/REPORT in their projects. [Stas] Add redirect tests [David Wheeler [EMAIL PROTECTED]] add -no-httpd runtime option to allow tests to run without configuring, starting, or stopping Apache. this essentially provides a direct Test::Harness interface through t/TEST, useful for running single tests that do not depend on Apache. [Geoffrey Young] Add support for Module::Build, with a new module: Apache::TestMB (a clone of Apache::TestMM for ExtUtils::MakeMaker). [David Wheeler [EMAIL PROTECTED]] switch the order of arguments in t_cmp() and t_is_equal() so that the order matches Test::More::is() and other Test::More functions. the new call is: t_cmp($received, $expected, $comment); support for $expected as the first argument marked as deprecated and will be removed in the course of the next few release cycles. [Geoffrey Young] add skip_reason() to Apache::Test, which provides a mechanism for user-specified skip messages [Geoffrey Young] Tweak Apache::TestRun to support test filenames starting with /(.\\)?t\\/ prefixes, windows style (needed for t/SMOKE) [Steve Hay]
Re: [RELEASE CANDIDATE] Apache-Test-1.12
Commenting out lines 669 and 1696 make it work fine. I remember having this discussion a few months back but did not find a solution. Apparently it is still an issue. Yup, but it was an issue with previous A-T releases as well, so it's not a showstopper. Someone who can reproduce this problem ought to find a fix. Commenting out code is not quite a fix. agreed. if nobody reports anything new over the weekend I'll release on monday so we get the TestMB stuff out there. --Geoff
