Apache-TestItSelf and Apache-TestMe
Finally I've polished and committed the first bits of Apache-TestItSelf, which is used to test that A-T's various config options actually work and that a new fix to one problem doesn't create a new one. At the moment there are just a few tests, but I'm going to write new ones as I discover problems and invite you to do the same. In order to keep the A-T's own test suite intact, I've created a new Apache-TestMe subproject, which contains solely tests to reproduce various problems (think geoff's bug skeleton). Originally I thought to just dump things into A-T's test suite, but then decided that it may break or complicate things. Regardless, the Apache-TestItSelf can be used to run any A-T based test suite, as the following extract from Apache-TestItSelf/README explains. The only inconvenience at the moment is that the config files include hardcoded paths, (since each one of us has apache/modperl installed at different locations), so I've created sample/ for you to copy away and adjust to reflect your setups. Apache-TestItSelf/lib/MyTest/Util.pm contains all kind of wrappers, which eventually should be polished into a nice API, but for now there are just that, wrappers to avoid dups. README: This test suite tests various Apache-Test setups (i.e. whether the configuration works correctly), something that can't be tested with the normal run-time test suite. 1) first of all move into Apache-TestItSelf % chdir Apache-TestItSelf 2) now choose which test suite to run again, to test whether some changes in A-T break its config, run 2a. But if the config testing coverage is not complete, try other test suites and then try to re-create this problem in 2a. You will need to adjust config files under sample/ to reflect the location of your preinstalled httpd and mod_perl files. a. Apache-Test config test suite % t/TEST -config sample/apache_test_config.pm this runs against the test suite under: Apache-Test/Apache-TestItSelf/Apache-TestMe/t it's the same as calling: % t/TEST -base ~/apache.org/Apache-Test/Apache-TestItSelf/Apache-TestMe/t \ -config sample/apache_test_config.pm b. Apache-Test assuming that Apache-Test is checked out under ~/apache.org/Apache-Test, the following will run the tests against the Apache-Test test suite % t/TEST -base ~/apache.org/Apache-Test \ -config sample/apache_test_config.pm c. modperl-2.0 assuming that modperl-2.0 is checked out under ~/apache.org/modperl-2.0, the following will run the tests against the modperl-2.0 test suite % t/TEST -base ~/apache.org/mp2-svn \ -config sample/modperl2_testitself_config.pm httpd_arg.t interactive.t d. 3rd party modules ### assuming that Apache-VMonitor-2.0 is checked out under ~/work/modules/Apache-VMonitor-2.0, the following will run the tests against the Apache-VMonitor-2.0 test suite. of course any other 3rd party module should do. % t/TEST -base ~/work/modules/Apache-VMonitor-2.0 \ -config sample/apache2_modules_testitself_config.pm -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
A-T: make dist puzzle
for some reason A-T's 'make dist' includes files which aren't in MANIFEST: Apache-Test-1.18-dev/.mypacklist Apache-Test-1.18-dev/t/cgi-bin/cookies.pl anybody has a clue why? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Allow loading builtin dso modules
Chia-Liang Kao wrote:
It seems I can never reach the list from my mail server.
May be apache.org blocks it?
Chia-Liang Kao, Please post messages inlined so it's easier to comment on
those. Inlining this one for you:
Auto-merging (0, 1125) /Apache-Test to /remote/Apache-Test (base
/remote/Apache-Test:1123).
Patching locally against mirror source
http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test.
U lib/Apache/TestConfig.pm
Patch - level 1
Source: 1bc2e5b2-7eeb-0310-aef5-f4fb8ed75f6b:/Apache-Test:1125
Target:
13f79535-47bb-0310-9956-ffa450edef68:/httpd/test/trunk/perl-framework/Apache-Test:122719
(http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test)
Log:
[EMAIL PROTECTED]: clkao | 2004-12-20 10:24:22 +0800
local branch
[EMAIL PROTECTED]: clkao | 2004-12-20 10:28:30 +0800
Allow core modules to be loaded explicitly with find_and_load_module.
This allows the apache from FreeBSD ports (with most modules built as
shared) to run tests with Apache::Test, and also allows testing svk
with a dav server.
* Apache/TestConfig.pm:
(find_and_load_module): New.
(generate_types_config): Use find_and_load_module to load mod_alias.
(httpd_config): Load mod_cgi and mod_access as they are part of the
core tests.
=== lib/Apache/TestConfig.pm
==
--- lib/Apache/TestConfig.pm (revision 122719)
+++ lib/Apache/TestConfig.pm (patch - level 1)
@@ -404,6 +404,9 @@
$self-{server}-post_config;
+$self-find_and_load_module ('mod_cgi.so');
+$self-find_and_load_module ('mod_access.so');
+
$self;
}
@@ -1204,6 +1207,18 @@
};
}
+sub find_and_load_module {
+my ($self, $name) = @_;
+my $mod_path = $self-find_apache_module($name) or return;
+my ($sym) = $name =~ m/mod_(\w+)\./;
+
+if ($mod_path -e $mod_path) {
+$self-preamble(IfModule = !$name,
+qq{LoadModule ${sym}_module $mod_path\n});
+}
+return 1;
+}
+
sub replace_vhost_modules {
my $self = shift;
@@ -1257,11 +1272,7 @@
# handle the case when mod_mime is built as a shared object
# but wasn't included in the system-wide httpd.conf
-my $mod_mime = $self-find_apache_module('mod_mime.so');
-if ($mod_mime -e $mod_mime) {
-$self-preamble(IfModule = '!mod_mime.c',
-qq{LoadModule mime_module $mod_mime\n});
-}
+$self-find_and_load_module ('mod_mime.so');
unless ($self-{inherit_config}-{TypesConfig}) {
my $types = catfile $self-{vars}-{t_conf}, 'mime.types';
@@ -1513,6 +1524,8 @@
my $out = $self-genfile($conf_file);
+$self-find_and_load_module('mod_alias.so');
+
$self-preamble_run($out);
for my $name (qw(user group)) { #win32/cygwin do not support
@@ -1534,14 +1547,6 @@
# handle the case when mod_alias is built as a shared object
# but wasn't included in the system-wide httpd.conf
-my $mod_alias = $self-find_apache_module('mod_alias.so');
-if ($mod_alias -e $mod_alias) {
-print $out EOF;
-IfModule !mod_alias.c
-LoadModule alias_module $mod_alias
-/IfModule
-EOF
-}
print $out IfModule mod_alias.c\n;
for (keys %aliases) {
BEGIN SVK PATCH BLOCK
Version: svk 0.26 (freebsd)
eJyNlM9v3EQUxxdEQrJAFQIU8VND40hJi7P22F7vumi1LbSVKKoQ2fQEWo3t512zXtuyZ5OuMEj2
pgiJctucuCAu9MQFBJcKDnDpqb3xR0SIKwcOPM8maZACRdqVxjPvfb7vvXnzLied8201a7WUTFKV
bPP6Vct6l3Gnv6rqmVTPwPV5lEhGFsA2BJKWBVFP0rOQDQFP02iUOOWCs6QHvFz4zgB4q6UirjHD
XRKIQ6yg2oxHYSo1Bb7LEwBJzfS2kbW18teV1GaWAp4IbDeBbT/1oxCFVZUaaIHmKrpHMYTdJIpK
ZZVSU222aemtZE4QpdAt8biDYHSgEqYkPFw/AQdjGpf5+LaAHQGEvHEAeGCJNkck7QQSaiKqdiFm
Th+E2sOJ9IioHybj+QFIVD/GqnUg5W9Goef3NuKhUH84WZuRxSmL42Dc5XCDuxBwJtQ0mhm24dk2
NZpKwzQbike9hmrXTVtTdc+u2xgF1fACr1Uqu9/Ud28/n58/XdlfqSwU06X8sd0vnysW8j9X5oup
NHmimG7Y+6/Of33xcVxV8q8q+y9s7a8u578Mns1/fWRucvfMU3+990wxXb5S3FpZ/PaTxcnv527O
Tb6AhfynTj6X//zSXP6HXSz8oCwW0+al4tYbiLyyNPlx/uViahfz+b2nlye3Xzxd7L3y6aliz5yb
3PngyWLv7VOT75Yqn31YfL6M8uhytvL9YrF3vYPaxb1q5Wa1uLtZyX97tLivh8x1ev6alI6Hw/c3
zrwmfYSrj9v68W4RtT+ojkZ1o2k2mEo1zzW1usbAYB40VMdhrqnWRc8YRjMjCbak3ma2RYgTDFhE
MkIVRZdVKlOFqIpFdYtSck5pKEqVBJHDAmInLHT6VeFr/Kdvw9KUQ98LQRDtECdKgAwjdxRASnhE
bEAoc8ElcCMOfMfnwZjs+LxPPD90uwz/5Xl35rJRJZ2+nxJWstC/D4SJNiNeEg3JZXyKFzffInGU
8JSsCcwwSvmRoD3yA05YWiVpnyXgrpchJKOQcOzSdKY761vLKhv3dYIBoFoaHUnirh/2SLo9qM7s
GXHZNkkh2YYE46uSs+Sk1reqhJC1k5Jat8g12NkQ5z0IIWEcunwcQ9p1hDcabKVwYkHK+MvPMsMu
C3yWzjh9zmP3gfs7hybYRSIlYe44kGItRR3HBOtBYpZwEnnlRokhs+sSxSm5VewbudWiGb6u2XTs
iBFnWVuhj+mnLFitZzjnYsb7OJ1w8uHHaOS7kkqzg4kgl2U5mIWShsPAdigYNpVNAFtWNFWRGXiG
7OFDboBrGl7dbq3T7N/Iup7VRLq1Ms4ax+sc1GJIAtlLcM7vRMngH8qH40doa57ZNDRD1k37QLvZ
NOqy5zHdUMAFr96QDP1/xWgdV7HK7P4GoC8suA==
END SVK PATCH BLOCK
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED]
Re: [PATCH] Allow loading builtin dso modules
Chia-Liang Kao wrote:
Allow core modules to be loaded explicitly with find_and_load_module.
This allows the apache from FreeBSD ports (with most modules built as
shared) to run tests with Apache::Test, and also allows testing svk
with a dav server.
* Apache/TestConfig.pm:
(find_and_load_module): New.
(generate_types_config): Use find_and_load_module to load mod_alias.
(httpd_config): Load mod_cgi and mod_access as they are part of the
core tests.
I like the find_and_load_module wrapper as it refactors some code dups.
But I don't think A-T should try to load any module someone may need in
their test suite. It does have a bunch of mp2 specific things which should
be wiped away and moved into the mp2 test suite.
This is your own test suite that you have the problem with, right? In
which case I'd prefer to see a patch which subclasses Apache::TestConfig,
so any test suite using A-T could decide which modules it wants to enforce
loading from t/TEST. As we don't have any examples of how to subclass
A-TC, let me know if you need help (it might be a tricky thing to do). You
can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL.
Another possible solution is to provide a t/TEST option -load_module,
which can be repeated several times, and will try to call your
find_and_load_module. So you could add it into t/TEST directly as if it
was passed from the command line.
+$self-find_and_load_module ('mod_cgi.so');
+$self-find_and_load_module ('mod_access.so');
+sub find_and_load_module {
+my ($self, $name) = @_;
+my $mod_path = $self-find_apache_module($name) or return;
+my ($sym) = $name =~ m/mod_(\w+)\./;
+
+if ($mod_path -e $mod_path) {
+$self-preamble(IfModule = !$name,
+qq{LoadModule ${sym}_module $mod_path\n});
+}
+return 1;
+}
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Allow loading builtin dso modules
Chia-Liang Kao wrote: On Sun, Dec 19, 2004 at 11:46:59PM -0500, Stas Bekman wrote: But I don't think A-T should try to load any module someone may need in their test suite. It does have a bunch of mp2 specific things which should be wiped away and moved into the mp2 test suite. Yes, originally I was trying to make the test load the module when it plans with need_module(). But I realized later that the config file was cached when MM/MB is invoked. So I forced it to load the two modules which A-T's own test wants. This is your own test suite that you have the problem with, right? In which case I'd prefer to see a patch which subclasses Apache::TestConfig, so any test suite using A-T could decide which modules it wants to enforce loading from t/TEST. As we don't have any examples of how to subclass A-TC, let me know if you need help (it might be a tricky thing to do). You can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL. As said earlier, this was to make A-T's test suite actually runs the cookie tests when mod_cgi is built as dso, and has nothing to do with my own tests. Aha! That wasn't clear from your description. And the access module, it's needed for the basic test suite too? My current tests are just using A-TC to write the config, not the whole TR framework, so I'm forcing the load of mod_dav_svn directly. (see: http://svn.clkao.org/svnweb/svk/checkout/trunk/t/50dav.t) Sweet! -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Allow loading builtin dso modules
On Sun, Dec 19, 2004 at 11:46:59PM -0500, Stas Bekman wrote: But I don't think A-T should try to load any module someone may need in their test suite. It does have a bunch of mp2 specific things which should be wiped away and moved into the mp2 test suite. Yes, originally I was trying to make the test load the module when it plans with need_module(). But I realized later that the config file was cached when MM/MB is invoked. So I forced it to load the two modules which A-T's own test wants. This is your own test suite that you have the problem with, right? In which case I'd prefer to see a patch which subclasses Apache::TestConfig, so any test suite using A-T could decide which modules it wants to enforce loading from t/TEST. As we don't have any examples of how to subclass A-TC, let me know if you need help (it might be a tricky thing to do). You can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL. As said earlier, this was to make A-T's test suite actually runs the cookie tests when mod_cgi is built as dso, and has nothing to do with my own tests. My current tests are just using A-TC to write the config, not the whole TR framework, so I'm forcing the load of mod_dav_svn directly. (see: http://svn.clkao.org/svnweb/svk/checkout/trunk/t/50dav.t) Cheers, CLK
Re: [PATCH] Allow loading builtin dso modules
On Mon, 20 Dec 2004 00:14:08 -0500, Stas Bekman [EMAIL PROTECTED] wrote: As said earlier, this was to make A-T's test suite actually runs the cookie tests when mod_cgi is built as dso, and has nothing to do with my own tests. Aha! That wasn't clear from your description. And the access module, it's needed for the basic test suite too? Yes. t/conf/extra.conf.in has Order allow,deny Cheers, CLK
Re: [PATCH] Allow loading builtin dso modules
Stas Bekman wrote: Chia-Liang Kao wrote: On Mon, 20 Dec 2004 00:14:08 -0500, Stas Bekman [EMAIL PROTECTED] wrote: As said earlier, this was to make A-T's test suite actually runs the cookie tests when mod_cgi is built as dso, and has nothing to do with my own tests. Aha! That wasn't clear from your description. And the access module, it's needed for the basic test suite too? Yes. t/conf/extra.conf.in has Order allow,deny Yup. I'll figure out how to fix that, w/o trying to load those modules for every test suite using A-T. (And I'll add your wrapper too find_and_load_module so it'll be in 1.18) thanks a lot, Chia-Liang Kao. well, I've cheated and for now simply dropped the requirement for mod_access from the config file. As for mod_cgi, it's properly conditioned. So the test shouldn't fail now (to start with). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
A-T: testmore failures
Geoff, when running A-T t/more: [Mon Dec 20 16:04:12 2004] [error] [client 127.0.0.1] failed to resolve handler `TestMore::testmorepm': -withtestmore error: Test::Builder version 0.18_01 required--this is only version 0.17 at /home/stas/apache.org/Apache-Test/t/../lib/Apache/Test.pm line 68. % perl5.8.6 -MTest::More -le 'print Test::More-VERSION' 0.54 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. So the client and server don't agree and this kind of failure happens. So I think the only solution to this is enforce that A-T tests require installed modperl. or something else needs to be done with t/more. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
