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? -- justin I ditched $_, see if it solves the problem. -- _ Stas Bekman mailto:[EMAIL PROTECTED] http://stason.org/ MailChannels: Assured Messaging(TM) http://mailchannels.com/ The Practical mod_perl book http://modperlbook.org/ http://perl.apache.org/ http://perl.org/ http://logilune.com/
Re: svn commit: r330356 - in /httpd/test/trunk/perl-framework/t: apache/ modules/ security/ ssl/
[EMAIL PROTECTED] wrote: Author: stas Date: Wed Nov 2 12:44:13 2005 New Revision: 330356 URL: http://svn.apache.org/viewcvs?rev=330356view=rev Log: tests requiring LWP when LWP is not available are now skipped A note for the test developers. For the future when you finish changing the test you are working on make sure that it either works or skipped when LWP module is not installed. To test run: APACHE_TEST_PRETEND_NO_LWP=1 make test or: APACHE_TEST_PRETEND_NO_LWP=1 t/TEST t/whatever/yourtest.t Apache-Test provides a limited emulation of LWP, so some tests work w/o requiring LWP. -- _ Stas Bekman mailto:[EMAIL PROTECTED] http://stason.org/ MailChannels: Assured Messaging(TM) http://mailchannels.com/ The Practical mod_perl book http://modperlbook.org/ http://perl.apache.org/ http://perl.org/ http://logilune.com/
Re: release canditates
Philip M. Gollucci wrote: Hi, I'd like to propose the following change to make rolling release candidates slightly easier. Instead of removing the -dev in ./Changes, we could change it to rc1, rc2, etc. The version would then be 'mod_perl-2.0.x-rcn' and the tarball would be mod_perl-2.0.x-rcn.tar.gz which untars into mod_perl-2.0.x-rcn/. +1, but see below A-T diff: -- /home/pgollucci/dev/repos/asf/perl/Apache-Test/trunk rv=0 165 svn diff Index: RELEASE === --- RELEASE (revision 327074) +++ RELEASE (working copy) @@ -3,7 +3,7 @@ 1. 'make dist' - to make sure nothing is missing from the manifest, etc. Now test this generated package (not svn) with as many configurations as possible on as many platforms as possible. - Note, in step 3a, removing the -dev line changes the package version + Note, in step 3a, changing the -dev line changes the package version name. i.e. (1.28-dev to 1.28) a. nuke any preinstalled Apache-Test libs and run 'make test' @@ -32,7 +32,7 @@ package to be released a. edit ./Changes: - - remove '-dev' + - change -dev to -rc\d+ start with -rc1 - add release date but where is the instruction to remove -rcX when doing the final release? -- _ Stas Bekman mailto:[EMAIL PROTECTED] http://stason.org/ MailChannels: Assured Messaging(TM) http://mailchannels.com/ The Practical mod_perl book http://modperlbook.org/ http://perl.apache.org/ http://perl.org/ http://logilune.com/
Re: [PATCH] fix mp2bug output to find httpd correct
Philip M. Gollucci wrote:
Hi,
[Sorry for the cross post, but I'm not really sure who's issue it is]
Note 2 patches, which one is best... MP2 or A-T (see below)
Under several situations, I can cause mp2bug to not find httpd or any
installed modules. More on the modules later.
The reason being is that
modperl/trunk/lib/Apache2/Build.pm::use constant IS_MOD_PERL_BUILD =
grep { -e $_/lib/mod_perl2.pm } qw(. ..);
Blows up. I'm pretty sure this happens under several circumstances.
I can name at least 2:
1.
/usr/home/pgollucci/dev/apps/perl-5.8.7/bin/perl Makefile.PL \
MP_APXS=/usr/home/pgollucci/dev/apps/httpd-2.3.0/bin/apxs \
MP_MAINTAINER=1 \
MP_DEBUG=1 \
MP_TRACE=1 \
PREFIX=/usr/home/pgollucci/dev/apps/mod_perl-2.0.2
ExtUtils::MakeMaker PREFIX breaks this as now you have a dir structure
mod_perl-2.0.2
bin/
mp2bug
lib
mod_perl2.pm
2.
/usr/home/pgollucci/dev/apps/perl-5.8.7/bin/perl Makefile.PL \
MP_APXS=/usr/home/pgollucci/dev/apps/httpd-2.3.0/bin/apxs \
MP_MAINTAINER=1 \
MP_DEBUG=1 \
MP_TRACE=1 \
This doesn't work for me either... Though I can't quite explain it as
easily.
Would it not make more sense to look for $_/Makefile.PL ?
Index: lib/Apache2/Build.pm
===
--- lib/Apache2/Build.pm(revision 279713)
+++ lib/Apache2/Build.pm(working copy)
@@ -26,7 +26,7 @@
use ExtUtils::Embed ();
use File::Copy ();
-use constant IS_MOD_PERL_BUILD = grep { -e $_/lib/mod_perl2.pm }
qw(. ..);
+use constant IS_MOD_PERL_BUILD = grep { -e $_/Makefile.PL } qw(. ..);
use constant AIX = $^O eq 'aix';
use constant DARWIN = $^O eq 'darwin';
*** OR **
It's too risky to just check for Makefile.PL, since it's too generic. What
if someone decides to run mp2bug while residing in the source directory of
some other perl distro? How about:
use constant IS_MOD_PERL_BUILD = grep
{ -e $_/Makefile.PL -e $_/lib/mod_perl2.pm } qw(. ..);
If not, this wors instead
[EMAIL PROTECTED]
/home/pgollucci/dev/repos/asf/perl/modperl/trunk/Apache-Test/lib/Apache
rv=0 426 svn diff
Index: TestConfig.pm
===
--- TestConfig.pm (revision 279713)
+++ TestConfig.pm (working copy)
@@ -2147,9 +2147,10 @@
# mod_perl 2.0 build always knows the right httpd location (and
# optionally apxs)
+# BUT bin/mp2bug does not neccessarily know this information
$vars_must_overriden++ if IS_MOD_PERL_2_BUILD();
-unless ($vars_must_overriden) {
+unless ($vars_must_overriden exists $args-{httpd}) {
for (@data_vars_must) {
next unless $Apache::TestConfigData::vars-{$_};
$args-{$_} = $Apache::TestConfigData::vars-{$_};
not really, I believe. It's possible that -httpd is not passed, in which
case this won't work.
--
__
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://mailchannels.com
Re: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
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. -- __ 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: Apache::Test v1.25 error - Can't use string (Test::Builder) as a HASH ref
Geoffrey Young wrote: 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 Sorry, I haven't tried it when you've reported it, but it seems to work fine: t/TEST -bugreport -verbose=0 t/more/02testmore.t setting ulimit to allow core files ulimit -c unlimited; /home/stas/perl/5.8.7-ithread/bin/perl5.8.7 /home/stas/apache.org/Apache-Test-unstable/t/TEST -bugreport -verbose=0 't/more/02testmore.t' the default base port is used, using base port 8569 instead /home/stas/httpd/prefork/bin/httpd -d /home/stas/apache.org/Apache-Test-unstable/t -f /home/stas/apache.org/Apache-Test-unstable/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.0.55-dev (prefork MPM) waiting 60 seconds for server to start: ok (waited 1 secs) server lapin.stason.org:8569 started t/more/02testmore[ info] the default base port is used, using base port 8589 instead request has failed (the response code was: 500) see t/logs/error_log for more details # Looks like your test died before it could output anything. t/more/02testmoredubious Test returned status 255 (wstat 65280, 0xff00) FAILED--1 test script could be run, alas--no output ever seen server lapin.stason.org:8569 shutdown error running tests (please examine t/logs/error_log) +-+ | To report problems please refer to the SUPPORT file | +-+ make: *** [run_tests] Error 1 2 So it's all good right? BTW, I've just synced the branch with the trunk. BTW, once svn.merge was run in the future, you just run it again, since it already sets the mergepoint at the end of its run. Joe Orton rocks! -- __ 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: [ANNOUNCE] Apache-Test 1.22
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. 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. -- __ 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: svn commit: r158805 - in httpd/test/tags/APACHE_TEST_1_21: ./ Changes
[EMAIL PROTECTED] wrote: Author: geoff Date: Wed Mar 23 09:39:13 2005 New Revision: 158805 URL: http://svn.apache.org/viewcvs?view=revrev=158805 Log: official 1.21 Added: httpd/test/tags/APACHE_TEST_1_21/ - copied from r158803, perl/Apache-Test/trunk/ httpd/test/tags/APACHE_TEST_1_21/Changes - copied unchanged from r158804, perl/Apache-Test/trunk/Changes This is no longer correct. the tag should be done in a different repository, where A-T now lives. -- __ 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: Apache-Test subdirectory has moved (again)
Geoffrey Young wrote: hi all... we (uh, I) kinda messed up during the first migration go-round and Apache-Test has moved once again, this time to a more svn-compliant directory structure. hopefully this will be the final resting place, at least for a while :) the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test/trunk what this means for you is that you need to manually adjust your checkout. again, I wasn't able to make this happen using anything short of $ rm -rf Apache-Test/ $ svn update but if you have a better way I'm sure we all would appreciate it. if you have any problems with access or permissions, just let me know and we'll get it sorted out. Always proves not to rush to update things :) I still didn't do any removes :) and many appologies for making this more painful than it needed to be. Thanks for doing the moving work, Geoff and Justin! -- __ 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: Apache-Test subdirectory has moved (again)
Geoffrey Young wrote: hi all... we (uh, I) kinda messed up during the first migration go-round and Apache-Test has moved once again, this time to a more svn-compliant directory structure. hopefully this will be the final resting place, at least for a while :) the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test/trunk what this means for you is that you need to manually adjust your checkout. again, I wasn't able to make this happen using anything short of $ rm -rf Apache-Test/ $ svn update It doesn't work for me. % rm -rf Apache-Test/ % svn up Apache-Test At revision 153479. it doesn't fetch the new Apache-Test. It seems that only a completely new checkout of the whole modperl-2.0 brings it in. -- __ 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: Apache-Test subdirectory has moved (again)
Geoffrey Young wrote: It doesn't work for me. % rm -rf Apache-Test/ % svn up Apache-Test At revision 153479. it doesn't fetch the new Apache-Test. It seems that only a completely new checkout of the whole modperl-2.0 brings it in. hmm, it worked for me. justin said something about needing to svn up twice on occasion, so maybe that was it - once to update the svn:externals property under mod_perl and one to use that new property to fetch A-T? Yes, that was it. But one needs to run 'svn up' *twice* at the root of the checkout. Thanks, Geoff. -- __ 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: Apache-Test subdirectory has moved
Geoffrey Young wrote: [...] 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. it doesn't matter, less work for us w/o it. 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++ -- __ 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: Apache-Test subdirectory has moved
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? -- __ 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: Apache-Test subdirectory has moved
Geoffrey Young wrote: 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? if you don't find any with grep, then there are none. So we should add one then :) 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. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? 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) -- __ 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: loading mod_perl first?
Geoffrey Young wrote:
+1
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);
}
--
__
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: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: 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? if you don't find any with grep, then there are none. So we should add one then :) 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. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? 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) 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 of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test
Oden Eriksson wrote: onsdag 26 januari 2005 00.47 skrev Stas Bekman: One thing I want to figure out is that note in README that suggests to write httpd.conf.in. Can we nuke that, or do you use that? Please leave as is. It can come handy. I for one wasn't able to get it to work as it's documented in that file. I think you said it did work for you. I didn't look at the code though. No, it didn't work exactly as stated in the docs, but close enough. what does close enough mean? In other words how do you think it should work? Should it not generate its own httpd.conf if it finds httpd.conf.in? -- __ 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: A-T: httpd.conf.in
Oden Eriksson wrote: [...] Now I have these failed tests with mod_perl-2.0.0-RC4: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/content_length_header.t 255 6528027 54 200.00% 1-27 t/api/aplog.t 36 13 36.11% 24-36 t/apr-ext/finfo.t 29 7424?? ?? % ?? t/apr-ext/util.t 29 7424?? ?? % ?? t/apr/finfo.t 255 65280?? ?? % ?? t/apr/util.t 255 65280?? ?? % ?? 3 tests skipped. Failed 6/222 test scripts, 97.30% okay. 40/2257 subtests failed, 98.23% okay. It seems some of them are because of some other matching bug in A-T. Attached is the error_log file. Oden, please post those to the modperl list following these guidelines: http://perl.apache.org/bugs/ -- __ 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: Apache-Test
Oden Eriksson wrote: But now I need to feed it with defines somehow and make it include module specific files from /etc/conf/conf.d/*.conf that should provide further info. This is tricky, but fun! If you explain what exactly do you mean, we may know how to make that easier. It is tricky due many reasons. Firstly certain files is prohibited to access as non root (we build packages as non root), As you have stated in the other emails this is a non-existing problem, right? If not let's go through this again, since I'm now not sure at all, if something is wrong. One thing I want to figure out is that note in README that suggests to write httpd.conf.in. Can we nuke that, or do you use that? I have to do work arounds, but that's no problem, secondly I'm no perl hacker and that's the fun part as it's a challange to make it work. :) -- __ 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: Apache-Test
One thing I want to figure out is that note in README that suggests to write httpd.conf.in. Can we nuke that, or do you use that? Please leave as is. It can come handy. I for one wasn't able to get it to work as it's documented in that file. I think you said it did work for you. I didn't look at the code though. -- __ 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: Apache-Test
Oden Eriksson wrote: torsdag 13 januari 2005 16.15 skrev Stas Bekman: Oden Eriksson wrote: [...] The system is clean except for parts of mod_perl 1.x that seems to be a requisite to get this mod_perl pick up missing pieces. Here's what's installed: what do you mean requisite? you mean mp2 requires mp1? Maybe it's a thing of the past, or I'm just too tired right now. At one time I saw something like Found mod_perl-1.x, good, will install relatively to Apache2/. And that message was despite the MP_INST_APACHE2=1 thing. Hmm, do you think it's a misleading message? I guess we could remove it if MP_INST_APACHE2=1 is used explicitly. Sorry for the delay. Here's the output of this: /usr/bin/perl Makefile.PL 'MP_CCOPTS=-O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -fPIC' MP_INST_APACHE2=1 MP_APXS=/usr/sbin/apxs2 MP_APR_CONFIG=/usr/bin/apr-config INSTALLDIRS=vendor Reading Makefile.PL args from @ARGV MP_CCOPTS = -O2 -fomit-frame-pointer -pipe -march=i586 -mtune=pentiumpro -fPIC MP_INST_APACHE2 = 1 MP_APXS = /usr/sbin/apxs2 MP_APR_CONFIG = /usr/bin/apr-config mod_perl/1.29 installation detected...ok (installing relative to Apache2/) Configuring Apache/2.0.52 mod_perl/1.999.20 Perl/v5.8.6 OK, but I fail to see what it has to do with you thinking that mod_perl 1 is required. If you didn't have modperl 1 installed you won't have had this message, no? -- __ 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: A-T: httpd.conf.in
Oden Eriksson wrote:
fredag 14 januari 2005 01.21 skrev Geoffrey Young:
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.
No no, please keep it, I just discovered it does work. Ths is my current way
to use it:
--- [snippet, start] ---
#!/bin/bash
if [ -f t/httpd.pid ]; then rm -f t/httpd.pid; fi
echo PidFile @ServerRoot@/httpd.pid t/conf/httpd.conf.in
echo AcceptMutex fcntl t/conf/httpd.conf.in
echo LockFile @ServerRoot@/httpd.lock t/conf/httpd.conf.in
echo TypesConfig /etc/httpd/conf/apache-mime.types t/conf/httpd.conf.in
for i in `/usr/sbin/apxs2 -q LIBEXECDIR`/*.so; do
new_name=`basename ${i}|sed 's/mod_//g'|sed 's/\.so//g'`
echo LoadModule ${new_name}_module ${i} t/conf/httpd.conf.in
done
make \
APACHE_TEST_COLOR=1 \
TEST_VERBOSE=1 \
APACHE_TEST_HTTPD=/usr/sbin/httpd2 \
APACHE_TEST_APXS=/usr/sbin/apxs2 \
test
--- [snippet, end] ---
The server fails to start, but that's something else. I noticed though that if
the /etc/httpd/conf/httpd.conf exists A-T is trying to inherit that config
(inherit_config) but this fails as this file is for apache-1.x. Shouldn't
something from httpd2 -V be used instead?
Take a look at: lib/Apache/TestConfigParse.pm:sub inherit_config {
it should find the correct global config file, please check that code to
see if something goes wrong.
Also the mod_perl module as all other code is built as non root, so certain
files and directories can't be access. The snipppet above solves some of
that.
A-T handles that internally. See
lib/Apache/TestRun.pm:sub adjust_t_perms {
if you intervene with normal process, then you are on your own.
I still can't understand what's wrong with the autogenerated httpd.conf,
that you need to write your own. Please explain.
--
__
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: Apache-Test
Oden Eriksson wrote:
I have been struggling for several hours now trying to understand how
Apache-Test is supposed to work with mod_perl-2.0.0-RC3, apache-2.0.52
and Mandrakelinux. I'm maintaining these softwares in Mandrakelinux.
Apache-Test seems to think it's a apache-1.x environment passing -D
APACHE1 and for example using Port in the generated config file. Even
though I have constructed a httpd.conf.in file it still wants to put Port
in the generated file. I'm very confused..., and no perl hacker.
don't touch httpd.conf. httpd.conf.in will be ignored. if you want to add
more config it has to be named differently. Please see:
Oh, I was reading Apache-Test/README and the Cheat List section. I says this
was the thing to do. I first tried to put my httpd.conf.in file in
Apache-Test/t/conf/ but that was ignored. Then I put it in t/conf/ and that
actually worked better until I got Port in the generated file for some
reason...
Hmm, I had no idea we had this feature. I guess it exists then. My
apologies for misleading you, Oden.
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configur
ation_Setup I guess it should say that people must not create httpd.conf.in.
please explain in detail (show the commands) what are doing, since I don't
understand how did you get A-T think it's running apache1.
Nothing fancy, make is (excuse the rpm stuff):
%{__perl} Makefile.PL \
%if %{build_debug}
MP_MAINTAINER=1 \
MP_TRACE=1 \
MP_CCOPTS=$(%{apxs} -q CFLAGS) -g3 -Werror \
%else
MP_CCOPTS=$(%{apxs} -q CFLAGS) \
%endif
MP_APXS=%{apxs} \
MP_APR_CONFIG=%{_bindir}/apr-config \
MP_INST_APACHE2=1 \
INSTALLDIRS=vendor /dev/null
make test gives:
unlimited; /usr/bin/perl5.8.5 /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t/TEST
-bugreport -verbose=0
[ error] Found mod_perl/1.999020, but it can't be used with
Apache-PREFORK-AdvancedExtranetServer/2.0.52
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
make: *** [run_tests] Error 1
Here I suspected it didn't like my funny server string, so I commented lines
61-65 in the Apache-Test/lib/Apache/TestRunPerl.pm file and that gives:
may be we should stop trying to parse the leading string and just gor for
/x.y.zz part. Otherwise we will never satisfy everybody.
[...]
/usr/bin/perl5.8.5 -Iblib/arch/Apache2 -Iblib/lib/Apache2 \
t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c
unlimited; /usr/bin/perl5.8.5 /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t/TEST
-clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
APACHE_TEST_APXS= \
/usr/bin/perl5.8.5 -Iblib/arch/Apache2 -Iblib/lib/Apache2 \
t/TEST -bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c
unlimited; /usr/bin/perl5.8.5 /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t/TEST
-bugreport -verbose=0
/usr/sbin/httpd2 -d /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t
-f /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
using Apache-PREFORK-AdvancedExtranetServer/2.0.52 (prefork MPM)
waiting 120 seconds for server to start: .Syntax error on line 27
of /home/oden/RPM/BUILD/mod_perl-2.0.0-RC3/t/conf/httpd.conf:
Port was replaced with Listen in Apache 2.0
Please post the output of:
% t/TEST -conf -trace=debug
I think what happens is this. MP_INST_APACHE2=1 tweaks Makefile to insert
mp2 modules into Apache2 subdir, but since you use a custom INSTALLDIRS it
fails to do that. And then:
if ($rev == 2) {
eval { require Apache2 require mod_perl };
} else {
eval { require mod_perl };
}
loads modperl1.
but I've just tried here with the same options and it works fine.
A-T is bundled with modperl and it's the one that should be run. Not any
previously installed A-T.
The system is clean except for parts of mod_perl 1.x that seems to be a
requisite to get this mod_perl pick up missing pieces. Here's what's
installed:
what do you mean requisite? you mean mp2 requires mp1?
$ rpm -ql mod_perl-common-1.3.31_1.29-3mdk | grep /usr/lib/
[...]
/usr/lib/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi/mod_perl_tuning.pod
--
__
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 patch] extend which() to search under perl's bin
Looks like a useful feature, needed to code it manually in libapreq test,
so why not include it in A-T.
the only question is may be it's better to search perl's bin first and not
last?
Index: Changes
===
--- Changes (revision 124937)
+++ Changes (working copy)
@@ -8,6 +8,10 @@
=item 1.20-dev
+extend Apache::TestConfig::which() to search under perl's bin
+directory (in the case of local perl install many utils get installed
+there, but won't be in PATH). [Stas]
+
Apache::TestConfig::inherit_load_module handles .dll modules
(previously was only .so) [Stas]
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 124937)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1643,7 +1643,13 @@
return undef unless $program;
-for my $base (map { catfile($_, $program) } File::Spec-path()) {
+my @dirs = File::Spec-path();
+
+require Config;
+my $perl_bin = $Config::Config{bin} || '';
+push @dirs, $perl_bin if $perl_bin and -d $perl_bin;
+
+for my $base (map { catfile $_, $program } @dirs) {
if ($ENV{HOME} and not WIN32) {
# only works on Unix, but that's normal:
# on Win32 the shell doesn't have special treatment of '~'
--
__
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: Apache-Test
Oden Eriksson wrote:
[...]
Please post the output of:
% t/TEST -conf -trace=debug
Attached.
So it has matched it as revision 1:
[ debug] Matched Apache revision
Apache-PREFORK-AdvancedExtranetServer/2.0.52 1
Frankly I have no idea how could it possibly happen.
And that's where the problem is coming from.
Please try this patch:
Index: lib/Apache/TestServer.pm
===
--- lib/Apache/TestServer.pm(revision 124937)
+++ lib/Apache/TestServer.pm(working copy)
@@ -67,15 +67,9 @@
# string and various variations made by distributions which mangle
# that string
-# Apache/2.0.50-dev
-($self-{rev}) = $self-{version} =~ m|^Apache/(\d)\.|;
+# Foo/x.y.z
+($self-{rev}) = $self-{version} =~ m|/(\d)\.|;
-# 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)\.|;
-
if ($self-{rev}) {
debug Matched Apache revision $self-{version} $self-{rev};
}
I think what happens is this. MP_INST_APACHE2=1 tweaks Makefile to insert
mp2 modules into Apache2 subdir, but since you use a custom INSTALLDIRS it
fails to do that. And then:
if ($rev == 2) {
eval { require Apache2 require mod_perl };
} else {
eval { require mod_perl };
}
loads modperl1.
but I've just tried here with the same options and it works fine.
I also tried to leave out MP_INST_APACHE2=1 as well as not having
mod_perl-common-1.3.31_1.29-3mdk installed.
I just saw this:
Warning: the following files are missing in your kit:
META.yml
But the file is there.
It's possible that Apache-Test/Makefile.PL is the one that has complained.
But ignore that for now.
A-T is bundled with modperl and it's the one that should be run. Not any
previously installed A-T.
The system is clean except for parts of mod_perl 1.x that seems to be a
requisite to get this mod_perl pick up missing pieces. Here's what's
installed:
what do you mean requisite? you mean mp2 requires mp1?
Maybe it's a thing of the past, or I'm just too tired right now. At one time I
saw something like Found mod_perl-1.x, good, will install relatively to
Apache2/. And that message was despite the MP_INST_APACHE2=1 thing.
Hmm, do you think it's a misleading message? I guess we could remove it if
MP_INST_APACHE2=1 is used explicitly.
--
__
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: Apache-Test
Stas Bekman wrote:
Maybe it's a thing of the past, or I'm just too tired right now. At one
time I saw something like Found mod_perl-1.x, good, will install
relatively to Apache2/. And that message was despite the
MP_INST_APACHE2=1 thing.
Hmm, do you think it's a misleading message? I guess we could remove
it if
MP_INST_APACHE2=1 is used explicitly.
That would be great! That would mean I don't have to have any apache_1
stuff installed when building this module.
OK, going to look at it.
Could you paste the exact message, Oden?
Take a look at modperl-2.0/Makefile.PL:
if ($build-{MP_INST_APACHE2}) {
print ok (installing relative to Apache2/)\n;
}
else {
The logic looks fine to me. If you have specified MP_INST_APACHE2=1 as
you've suggested above, it'd have printed:
print ok (installing relative to Apache2/)\n;
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Recent problem with Apache::Test v. 1.19
Barry King wrote: Hello: I cannot test Apache::Test version 1.19 on Debian woody (5.006001) because of problems compiling Cwd on perl 5.6. However, it does compile on darwin (5.008001). FYI -- a strange result comes up when using Cwd during the test on darwin: -- use strict; use warnings; no warnings qw(uninitialized); use Cwd; use Apache::Test; use Apache::TestUtil; use Apache::TestRequest qw(GET_BODY GET_OK); use Apache::Wyrd::Services::Index; my $directory = getcwd(); $directory = $directory/t if (-d 't'); my $count = count; print 1..$count\n; my $index = undef; print not unless (GET_OK '/13.html'); print ok 1 - Index creation\n; [...] it fails at the first invocation of GET_OK with the error that the top directory is not exported by the lib module (Apache::TestConfig invokes lib-(top directory). I can circumvent it by invoking: eval 'use lib top directory' before calling GET_FOO, but this is a little kludgy. sorry, I don't understand your interpretation of the errors, Barry. Any chance we can see the exact errors? The requirement for Cwd 2.06 was needed to get the tests running under -T, which was otherwise blowing up (precisely under 5.6.x). If there are problems with Cwd please contact the author of that module. I've added the prerequisite when I saw that it's available on CPAN and builds fine on linux under 5.6. -- __ 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: httpd.conf.in
As Oden has pointed out, the custom httpd.conf.in advertised in the README doesn't work. I've confirmed yet. So I suppose this feature existed before but was lost. So should we just nuke it from README? Or should we implement it? If the latter I'd like to add a test for it, so it's not again lost in the flurry of changes. 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 -- __ 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: Recent problem with Apache::Test v. 1.19
Christopher H. Laco wrote: Stas Bekman wrote: [snip] The requirement for Cwd 2.06 was needed to get the tests running under -T, which was otherwise blowing up (precisely under 5.6.x). If there are Just for my learning, which version of -T? [t/mytest.t] #!perl -wT use Apache::Test; or PerlTaint On or perl -wT t/TEST or make test? There is only one version of taint, it doesn't matter how you invoke it. It was blowing up when File::Spec::rel2abs was used. Search this list's archives for that module to find the right thread discussing this problem. In the project I'm currently working on, it's all running under 5.6.1 w/A-T 1.16, stock Cwd 2.04 without any blowups under the first and third options. All hell breaks loose when I try PerlTaint on, but those appeared to be AxKit issue in my case. The difference is not first/third vs. second, but plain perl vs. mod_perl. Under mod_perl there are many things happening which don't happen under plain perl. The main cause is a persistance of things. So some totally unrelated code may cause taint problems. So you need to seek the cause and fix it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[A-T patch] changing should_skip_module to support regex skip patterns
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.
The only bad things about this change is that it slows things a bit (now
needs to iterate over all entries in skip list on each module, previously
it was a single hash lookup).
Nick, also please confirm that the patch below *does* work for you :) Thanks.
Nick *** wrote:
Nick *** wrote:
Are you running the latest dev svn?
The latest svn is fine. I just removed the patch in order to test more
this issue, and that's the coredump...
Understood. I certainly don't have the time to look at fastcgi problems at
the moment. If someone can that would be great.
so we are all well on this setup. Great!
Not quite well with RC3.
When executing this code in TestRun.pm
# - don't inherit LoadModule perl_module from the apache httpd.conf
# - loaded fastcgi crashes some mp2 tests
my %skip = map { (mod_$_.c = 1) } qw(perl fastcgi);
sub should_skip_module {
my($self, $name) = @_;
print \n\n$name\n\n;
exists $skip{$name} ? 1 : $self-SUPER::should_skip_module($name);
}
and checking for fastcgi, the value of $name is 'mod_fastcgi-2.4.2-AP20.dll' and not 'mod_fastcgi.c', so the module is loaded and the tests fail again.
Please try this patch:
Index: lib/ModPerl/TestRun.pm
===
--- lib/ModPerl/TestRun.pm (revision 124346)
+++ lib/ModPerl/TestRun.pm (working copy)
@@ -64,12 +64,9 @@
# - don't inherit LoadModule perl_module from the apache httpd.conf
# - loaded fastcgi crashes some mp2 tests
-my %skip = map { (mod_$_.c = 1) } qw(perl fastcgi);
-sub should_skip_module {
-my($self, $name) = @_;
+my @skip = ('mod_perl.c', qr/mod_fastcgi.*?\.c$/);
-exists $skip{$name} ? 1 : $self-SUPER::should_skip_module($name);
-}
+Apache::TestConfig::autoconfig_skip_module_add(@skip);
1;
Index: Apache-Test/lib/Apache/TestConfigParse.pm
===
--- Apache-Test/lib/Apache/TestConfigParse.pm (revision 124346)
+++ Apache-Test/lib/Apache/TestConfigParse.pm (working copy)
@@ -162,20 +162,28 @@
#XXX mod_jk requires JkWorkerFile or JkWorker to be configured
#skip it for now, tomcat has its own test suite anyhow.
#XXX: mod_casp2.so requires other settings in addition to LoadModule
-my %autoconfig_skip_module = map { $_, 1 } qw(mod_jk.c mod_casp2.c);
+my @autoconfig_skip_module = qw(mod_jk.c mod_casp2.c);
# add modules to be not inherited from the existing config.
# e.g. prevent from LoadModule perl_module to be included twice, when
# mod_perl already configures LoadModule and it's certainly found in
# the existing httpd.conf installed system-wide.
sub autoconfig_skip_module_add {
-my($name) = @_;
-$autoconfig_skip_module{$name} = 1;
+push @autoconfig_skip_module, @_;
}
sub should_skip_module {
my($self, $name) = @_;
-return $autoconfig_skip_module{$name} ? 1 : 0;
+
+for (@autoconfig_skip_module) {
+if (UNIVERSAL::isa($_, 'Regexp')) {
+return 1 if $name =~ /$_/;
+}
+else {
+return 1 if $name eq $_;
+}
+}
+return 0;
}
#inherit LoadModule
@@ -192,7 +200,8 @@
}
my $name = basename $args-[1];
-$name =~ s/\.s[ol]$/.c/; #mod_info.so = mod_info.c
+$name =~ s/\.(s[ol]|dll)$/.c/; #mod_info.so = mod_info.c
+$name =~ s/\.dll$/.c/; #mod_info.so = mod_info.c
$name =~ s/^lib/mod_/; #libphp4.so = mod_php4.c
$name = $modname_alias{$name} if $modname_alias{$name};
--
__
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: Hi Stas, Merry Christmas and thanks for the xmas modperl rc. :) You too :) I just noticed that I was doing something wrong for find_and_load_module. It checks .so rather than .c in IfModule, and this causes modules being loaded twice if they are compiled in. I've noticed that too, but didn't have a chance to look at it yet. do you have a patch? On Sun, 19 Dec 2004 23:46:59 -0500, Stas Bekman [EMAIL PROTECTED] wrote: (find_and_load_module): New. I like the find_and_load_module wrapper as it refactors some code dups. -- __ 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: Just produced one. On Sat, 25 Dec 2004 09:51:37 -0500, Stas Bekman [EMAIL PROTECTED] wrote: I've noticed that too, but didn't have a chance to look at it yet. do you have a patch? Patching locally against mirror source thanks Chia-Liang Kao, committed with a tiny tweak. -- __ 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: A-T: testmore failures
Geoffrey Young wrote: 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 :) Perfect, go for it Geoff. The mp2 fix is in. -- __ 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
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] http
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
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
Re: svn commit: r111983 - /httpd/test/trunk/perl-framework/Apache-Test/ToDo
[EMAIL PROTECTED] wrote: Author: stas Date: Wed Dec 15 08:08:52 2004 New Revision: 111983 URL: http://svn.apache.org/viewcvs?view=revrev=111983 Log: - general config: adjust Apache/TestConfig.pm not to write irrelevant httpd.conf sections (e.g. IfModule prefork.c for win32, and vice versa, A-T knows exactly what mpm it needs to write the config for). Thus reducing the clutter. - winnt case: Apache/TestConfig.pm config for IfModule mpm_winnt.c before Apache-2.0.50 ThreadsPerChild had to be at least as big as the number of Vhosts. This was fixed in 2.0.50. Since A-T knows the httpd version, it shouldn't start so many threads for httpd = 2.0.50, but @[EMAIL PROTECTED] Also add BACK_COMPAT_MARKER in the logic so when no longer support httpd 2.0.50, this logic could be removed. Chris, if you are still looking at what to do to improve A-T, I think this two new todo items might be of interest to you. -- __ 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: svn commit: r111983 - /httpd/test/trunk/perl-framework/Apache-Test/ToDo
I still need to take a crack at the mp2 RC and see if it will build on my setup as well. that's definitely more important! I would think so. I did a quick test that night, and I still couldn't do a stock perl Makefile.PL and have it find libs without doing perl Makefile.PL MP_AP_PREFIX=C:\Development\Apache2 instead. I thought there were a few patches for that, but maybe not. You are on the mined win32 land, nothing is taken for granted there. If an explicit path works, that's already a great thing (of course thanks to Randy's magic) since I hadn't spent more than 2 minutes on the process, I didn't submit a bug report as of yet. OK, but make sure that we contrinue modperl thread on the modperl dev list and not here :) Thanks. -- __ 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
Apache-Test/Makefile.PL r105822
Geoff,
This change:
http://svn.apache.org/viewcvs.cgi/httpd/test/trunk/perl-framework/Apache-Test/Makefile.PL?rev=105822r1=105299r2=105822diff_format=h
adding:
if ($ExtUtils::MakeMaker::VERSION 6.06) {
# now that we're using subversion, make sure that
# .svn directories are skipped during the build process
# for old versions of MakeMaker
sub MY::libscan {
my $self = shift;
my $path = shift;
return '' if $path =~ /\B\.svn\b/;
return $path;
}
}
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:
% perl -le 'if ($_ == 1) { sub a { print a } }; a()'
a
Moreover it now introduces a warning in mp2 build
Subroutine MY::libscan redefined at ./Makefile.PL line 148.
so we need to do the usual ugly workaround for MM :(
Can you fix those? I can do it if you don't have the time.
--
__
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: Apache-Test/Makefile.PL r105822
Geoffrey Young wrote: 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. No worries :) There is a way too many things to think about. 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? I mean usual MM namespace workarounds, not specific to A-T :( 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? to make the sub definition runtime, you just use: *MY::foo = sub ...; but unrelated we need to workaround with colliding identical function in mp2. I'll take care of it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] module2path/module2url pod
Christopher H. Laco wrote: Here's my first crack at pod for module2path and module2url. I decided to put it at the end of the FUNCTONS head1. It didn't seem to make much sense at the beginning and it felt like I should keep focus on the exported functions. There is already one head1 FUNCTIONS there. I've called your header: =head2 URL Manipulation Functions since all function in this module are 'helper functions' :) Let me know if you had something else in mind and I'll rework it. Looks good. I've massaged it a bit and commited. Thanks Chris. -- __ 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: apxs calls on Win32
Randy Kobes wrote: On Wed, 8 Dec 2004, Stas Bekman wrote: I've requested to restore it (you indeed don't have it). Let me know if you want me to commit this or wait for when you get the access again (should hopefully be restored tomorrow). Thanks, Stas. If you have a minute, feel free to commit it; otherwise, I'll do it when it's restored. Thanks. It's in. -- __ 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: [OT] CVS - SVN Thoughts
Christopher H. Laco wrote: This is mostly off topic, but I wanted to get thoughts from the committers on how they're liking the conversion from CVS to SVN so far. What do you really like/hate about it vs. CVS? I've been toying around with the idea of moving that way at home. I'm not to sure I'm keen having to use copy for tagging and such, but maybe that's just the CVS brainwashing in me. I do dig the http/WebDAV background. It seems a lot easier to give the world read access. I guess this is a wrong forum. May be you will have a better luck with svn users list, whatever it is? Personally I haven't done any moves myself yet, so I can't tell. -- __ 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] module2path/module2url pod
Christopher H. Laco wrote: Shouldn't that be: Index: TestRequest.pm - $url = Apache::TestRequest::module2url($module, %options); + $url = Apache::TestRequest::module2url($module, \%options); Thanks Chris, fixed. Any other grunt work can work on? if you didn't get tired from module2url manipulations, there are a few tests in the httpd-test repository that could use the same refactoring. This is the repository used by the httpd project. To exract it do: svn checkout http://svn.apache.org/repos/asf/httpd/test/trunk/ httpd-test it lives in httpd-test/perl-framework/t/ Other than that, I'm going to commit soon a new test framework that tests Apache-Test config itself, so you may want to help out with that, once it's in. You are on the [EMAIL PROTECTED] list, right? That list shows all the commits to the httpd-test project (which includes Apache-Test). -- __ 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] Test TestRequest pod
Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = Frankly I can never tell the difference (I know there is one). I normally use url... but whatever you like -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? If you use a relative path, it just goes to the default http://localhost:8529/. Not madness but for the sake of simplicity. Use relative path, unless you want to talk to a different port. -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Baby steps, Chris. Baby steps. :) I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. chris++ -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris -- __ 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: apxs calls on Win32
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Thanks for the research, Randy.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
+1
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
I think you can diff/ci only if you first cd into A-T dir. so it'll go to
the right list anyway. So there is no way you can commit the two at once I
think.
--
__
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: apxs calls on Win32
Randy Kobes wrote:
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
If it's only win32 case then +1 but if other platforms may have the same
problem, may be it's better to blindly launder $ENV{PATH} like we do in a
few other places (in which case there will be no need for this change, as
the right paths will be there already, correct?)
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 109825)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1658,6 +1658,12 @@
my $val;
unless (exists $self-{_apxs}{$q}) {
local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+# need path to Perl and to cmd.exe on Win32
+if (WIN32) {
+$ENV{PATH} = sprintf(%s;%s,
+ dirname($ENV{COMSPEC}),
+ dirname($self-{vars}-{perl}));
+}
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
populates $ENV{PATH} with the needed paths so that these
calls succeeed.
--
__
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] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Stas Bekman wrote: Still someone needs to do the work and verify that things are working. That will fun in and of itself. Right now, the only thing close to meeting the requirements of running the overall tests is my 5.6.1 install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03. It'll probably take some time just to get my unmodded working copy to run all of it's test before I even start coding. I may just have to whip up another FBSD tinker box. -=Chris And so it starts. I'm having problems subscribing to the modperl-win32 list at the moment, otherwise I'd ask this there. I had no idea such list exists. Is there any other way to test my changes other than trying to build mp2 itself? Probably not, since it relies on the fact that it has an access to the source. I want to get started on the changes but I can get mp2 to build on Win32: Configure mod_perl with C:\Development\Apache2? [y] Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4 Note (probably harmless): No library found for /lib/libapr.lib Of course, my %LIB% contains the appropriate Apache2/lib directory and that dir is also in my Config.pm. Thanks for putting up with the newb. Please post this question to the modperl-dev list (with a relevant subject): http://perl.apache.org/maillist/dev.html and Randy will be able to help you. (I'm of no help on win32) -- __ 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] Test TestRequest pod
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be the
most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
but committed anyway :)
--
__
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] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional
headers via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \ and . The bare versions seemed to be
the most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
I assume you mean http://svn.apache.org/repos/asf/httpd/test/trunk/, and
not just the root of Apache-Test correct?
No, no, the root of A-T. An example will be more useful:
--- lib/Apache/Test.pm (revision 109410)
+++ lib/Apache/Test.pm (working copy)
I can chdir into the root of the project and apply your patch immediately.
Index: TestRequest.pm
+ Apache::TestRequest::user_agent(reset =,
+ cookie_jar = {});
Sorry, but what's that 'reset = ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar = {});
as in the test.
Geez. Apparently I'm in the clouds this week. Maybe I need to do these
changes during the day instead of at night. :-/
:)
=head1 FUNCTIONS
CApache::TestRequest exports a number of functions that will likely
@@ -837,6 +850,11 @@
Sends a simple GET request to the Apache test server. Returns an
CHTTP::Response object.
+You can also supply additional headers to be sent with the request
+by adding their name/value pairs after the Curl parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Well, yes, and that was on purpose. I hated reading the A-T pod and
never knowing there was an extra param for GET. THe pod usualy is enough
to get start, and I wouldn't exptec to have to read:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Agreed, but dups are evil from the maintenance point of view. I'd rather
have everything in one place and have the other document link to the first
one. Unfortunately A-T pods are nowhere on perl.apache.org.
Were you looking for something more extensive?
No, no, it's perfectly fine. The next person looking for the same solution
will most likely easily find it.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
--
__
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: need to require Cwd 2.06 for A-T
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
So it's:
WriteMakefile(
NAME = 'Apache::Test',
VERSION = $VERSION,
PREREQ_PM = { 'File::Spec' = '0.8',
'Cwd'= '2.06',
},
...
);
but if this is not run from CPAN/CPANPLUS shell, most likely this
requirement will be ignored. Should we add:
die Cwd 2.06 or higher is required
unless eval { require Cwd $Cwd::VERSION = 2.06 };
after WriteMakefile(), this won't get on the way of CPAN/CPANPLUS shell
will it?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need to require Cwd 2.06 for A-T
Geoffrey Young wrote: 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. It can affect any test, the problem is triggered by A-T. Any File::Spec-rel2abs call may trigger the problem. It just happens to be triggered so far under mp2 tests. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to
do for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
Hmmm, sounds easy enough since you already included module2url. :-)
Famous last words.
Still someone needs to do the work and verify that things are working.
Is this just a concern in t/modperl? I came up with 77 hits in t/, and
11 of those are in t/modperl. Maybe that small subset is a same place
for me to start.
It's all t/. But you can start with a subset.
Am I correct in assuming that the modperl in SVN is the 2.0 trunk (the
one I want) and that 1.0 is stuck back in CVS? I'm still trying to wrap
my brainpan around what modules are where and what perl-framework really
encompasses.
That's correct. I tried to argue that we want it to be called modperl-2.0,
but the httpd-way was preferrable on other developers.
The online docs have all the info:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
--
__
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] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
I think all kind of refactoring would be great. One thing I wanted
to do for tests again vhosts, is to add this function next to
module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so
now one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar = /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme = 'https',
path = '/merge3/
}
Isn't merge3 an odd ball? Originally I was thinking to do the refactoring
for the code which identical and leave the more complex cases alone. But
if you wish to implement the suggested functionality go for it. It
definitely makes the test more readable, and those wishing to use the old
functionality still can do that.
though it's module2url, not module2path (saw your update)
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
--
__
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] Test TestRequest pod
Christopher H. Laco wrote:
Stas Bekman wrote:
Of course it should take the necessary precautions for when / is and
isn't included, etc.
What do you mean? Examples?
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path = 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
You are correct. Then yes, if the $path argument is provided by the user
strip the leading /.
--
__
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
httpd-test pages need to be updated to point to svn not cvs
http://httpd.apache.org/test/ is outdated (s/cvs/svn/)... thanks. -- __ 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: httpd-test pages need to be updated to point to svn not cvs
Randy Kobes wrote: On Tue, 30 Nov 2004, Stas Bekman wrote: http://httpd.apache.org/test/ is outdated (s/cvs/svn/)... thanks. I just changed, via svn, the site/docs/test/index.html and site/xdocs/test/index.xml pages to reflect this. Thanks Randy However, I just wanted to verify that, to get the changes on the site itself, one must $ ssh cvs.apache.org $ cd /www/httpd.apache.org/test $ svn up Thanks. It wasn't updated yet, so I did the above and now it's updated. But for some reason the headers License + search site are shifted to the right (wrong level?) -- __ 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: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Thanks, Chris, committed with a few small adjustements. You can see the commits here: http://svn.apache.org/viewcvs?view=revrev=109277 http://svn.apache.org/viewcvs?view=revrev=109279 Thanks. Glad to contribute. It looks like the only change was naming the cookies.pl to cookies.pl.PL. That was needed to get the path to #!perl right What cnvention did I miss so I don't make that mistake again? The only missing thing was to check that CGI and CGI::Cookie were available in plan(). I moved htdocs/cgi-bin/ = cgi-bin/ and did a few minor syntax changes. You can see what was applied at the URLs quoted at the top of this email. Now looking forward for docs updates. Thanks again. -- __ 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: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
just a very simple test that verifies that the documented technique
works. later on it may evolve to include a special A-T API if we ever
add one.
Is it enought to do IfModule mod_usertrack.c and also
need_module(mod_usertrack.c) to determine if the usertrack mnodule is
installed, or is there someplace deeper within the setup where we can
actually add LoadModule mod_usertrack.c?
for config it's enough for the code it's:
plan tests = 5, need_module('usertrack');
but most people won't have this module installed...
--
__
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: Apache::TestRequest + Cookies
Christopher H. Laco wrote: but most people won't have this module installed... Installed, or loaded? I know the httpd.conf defaults to having that module commented out, but the module itself should be around. Loaded or even available... Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t -- __ 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: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Christopher H. Laco wrote: CChristopher H. Laco wrote: Maybe relying on Apache::Session would cover more install scnerios instead. I was trying to avoid writing a custom handler just to accept and toss some cookies in the test environment, but maybe that's better. At least then everyone install should be able to run the A-T cookie test. I think the same_interp setup will do what you want. e.g. see in modperl-2.0 repository this test couple: t/response/TestModperl/sameinterp.pm t/modperl/sameinterp.t Holy crap. That made my brain hurt. Would we use that directly, or just borrow the idea? Why don't you first post what you had on your mind. May be your idea doesn't need that at all. -- __ 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: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
Stas Bekman wrote:
[snip]
Why don't you first post what you had on your mind. May be your idea
doesn't need that at all.
Well, here's what I was thinking. First, write a quick and dirty
mod_perl handler that looked for a specific cookie; let's say 'ApacheTest'.
If it wasn't supplied by the client, send a new copy out. If it was sent
by the client, simply return the supplied cookie/value.
Shouldn't take more than a few lines of code, and it removes the
dependency of usertrack and Apache::Session.
Then, simply write a test that makes a series of requests to that
handler. The first response should return a new ApacheTest cookie/value,
and the second test should pass back the same ApacheTest cookie/value if
Apache::TestRequest::user_agent( cookie_jar = {});
and it's surroundings are woroking fine.
Sounds good. Though it'll probably need to leave in the modperl2's test
suite and not Apache-Test's one. but let's see the code first and then see
where it's the best to apply it. You can use the
http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
to make it easy to write the test.
--
__
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: FW: Re: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Stas Bekman wrote: Sounds good. Though it'll probably need to leave in the modperl2's test suite and not Apache-Test's one. but let's see the code first and then see where it's the best to apply it. You can use the http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz to make it easy to write the test. I guess that's where I'm getting confused. Why would this be in mp2 rather than in A-T, since I'm really trying to confirm a scenerio under A-T. Obviously there's something I'm missing. It should be in A-T, but since your test requires modperl it'd be better be in modperl, since chances are that A-T won't have modperl available and then it'll be skipped. So may be your original mod_usertrack idea was better, as it doesn't depend on mod_perl's availability (but at the same time depends on mod_usertrack). The reason I'm OK with adding A-T tests to modperl is that we run modperl2 tests all the time, much more often than A-T tests, so it's probably a second best place to put those cookie tests. In fact you can already find some cookie tests in the modperl2 test suite (against CGI.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
Re: Pickyness question
Christopher H. Laco wrote:
Just because I'm like that. :-)
I noticed in A-T/t/redirect.t we have:
plan tests = 6, need_module('mod_alias.c') need_lwp;
Of course, I noticed this after skimming over the A-T pod again , where
it mentions:
It's also important to mention to avoid using:
plan tests = 1, requirement1 requirement2;
Yes, it's wrong, I will fix that. The doc is correct.
For that matter, sometimes I see:
1) plan tests = 1, need_lwp;
2) plan tests = 1, need_lwp;
3) plan tests = 1, \need_lwp;
From a pure A-T coding standpoint, which is preferred?
That's a totally different issue. Either 1 and 3 will work. since if it
gets a CODE ref it'll run it.
2 will also work but it's not the best way to call a function which
accepts not args, since when you call foo, @_ is passed to it (see
perlsub.pod)
NAME; # Makes current @_ visible to called subroutine.
so if it has an empty prototype, that would be an error.
--
__
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: svn commit: r109235 - /httpd/test/trunk/perl-framework/Apache-Test/t/redirect.t
Geoffrey Young wrote:
-plan tests = 6, need_module('mod_alias.c') need_lwp;
+plan tests = 6, need need_module('mod_alias.c'), need_lwp;
^
?
:)
Garbage in, garbage out :) now fixed :)
--
__
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: extending t_cmp to handle !t_cmp?
Geoffrey Young wrote: - We still don't have Test::More in the 5.6.1 core (it was added in 5.6.2/5.8.0), so we can't rely on it being available. sure, but you can conditionally skip over those tests for users that don't have Test::More installed. I know that currently doing that is kind of ugly, but we could come up with some pretty shortcuts for this if you like. Am I correct to say that Test::More is in the core for all but 5.6.1 the required minimum by mp2? 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? 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? - Test::More's verbose output doesn't work the way we want, it prints out the expected/received values only on failure, making it really hard to develop tests. that's a matter of personal preference - I very much prefer the behavior of is() to t_cmp() :) I understand that Test::More's behavior is preferrably at run time, 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? That's the only reason why I prefer t_cmp() to is(). anyway, I understand your concerns, so go ahead and implement it if you like. it just feels really, really bad to continue moving as though the Perl community hasn't already solved these problems with what is considered to be the standard testing module. At the moment I'm fine. -- __ 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: extending t_cmp to handle !t_cmp?
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. -- __ 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: Apache::TestRequest + Cookies
Christopher H. Laco wrote:
Now that I've gotten a few other module updates out of the way, I want
to get back to the thought of cookies within A-T. Two things were
mentioned that would help the A-T project in some way.
First, possibly add pod doc on how to use cookies within A-T using
Michaels solution of
Apache::TestRequest::user_agent( cookie_jar = {});
+1
and possibly others. I would also probably take a stab at getting some
of the other things in
http://perl.apache.org/docs/general/testing/testing.html into the pod;
specifically the use of the secondary param in the GET request to add
outgoing headers and the like.
+1
Second, add some sort of cookie tests to the A-T test suit. I'm not
quite sure what a test would be for other than to verify that A-T using
LWP actually receives and sends cookies and verifies they get remembered
between requests. But that seems more like testing LWP and A-T to me.
just a very simple test that verifies that the documented technique works.
later on it may evolve to include a special A-T API if we ever add one.
My first thoughts are to keep it as simple as possible and check for
mod_usertrack. It it's there, ensure the first tracking cookie value is
maintained across multiple requests.
Whatever you find the best is fine with us. You may want to use the
same_interp framework in case you need to make sure that you hit the same
perl interpreter (in case you store some data on the server side). See the
tests in modperl-2.0/t for examples.
--
__
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: is it safe to enable Lockfile for all mpms across all apache generations?
Stas Bekman wrote: Joe Orton wrote: On Wed, Nov 24, 2004 at 04:45:18PM -0500, Stas Bekman wrote: It looks like some poeple have a problem with LockFile directive being compiled to a hardcoded value. The problem: [Tue Nov 02 17:16:22 2004] [emerg] (13)Permission denied: Couldn't create accept lock Is it safe to set LockFile for all mpms? Yes, looks like it should be. For apache 1.3? I think so too. Excellent, thanks Joe! Unfortunately it's not the case. winnt croaks on this directive. http://httpd.apache.org/docs-2.0/mod/mpm_common.html#lockfile Module: leader, perchild, prefork, threadpool, worker so I adjusted it to be enabled for those mpms that support it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
extending t_cmp to handle !t_cmp?
Most of the time when one needs to check when two values are different one could run: ok !t_cmp(...) but the diagnostics is wrong, since received will be matching 'expected' For example: ok !t_cmp $received, qr/message/ # testing : whatever # expected: (?-xism:message) # received: [...] [notice] [client 127.0.0.1] message must not appear! not ok 32 so the verbose output is confusing. so we probably need to introduce a new directive t_cmp_no() or something similar which will be run as: ok t_cmp_no $received, qr/message/ and log as: # testing : whatever # expected: ! (?-xism:message) # received: [...] [notice] [client 127.0.0.1] message must not appear! not ok 32 or something like that. internally it'd run !~, neq and != depending on the arguments. Comments? -- __ 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: [ANN] gmane now carries httpd-test
Joe Schaefer wrote: news.gmane.org now provides nntp access to this list. The newsgroup's name is gmane.comp.apache.httpd.test.devel Thanks Joe. I wish their search was a bit faster. -- __ 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: is it safe to enable Lockfile for all mpms across all apache generations?
Joe Orton wrote: On Wed, Nov 24, 2004 at 04:45:18PM -0500, Stas Bekman wrote: It looks like some poeple have a problem with LockFile directive being compiled to a hardcoded value. The problem: [Tue Nov 02 17:16:22 2004] [emerg] (13)Permission denied: Couldn't create accept lock Is it safe to set LockFile for all mpms? Yes, looks like it should be. For apache 1.3? I think so too. Excellent, thanks Joe! -- __ 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: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Has anyone used ApacheTestRequest to test pages using cookiessessions? I'm writing some quick and dirty tests for an AxKit session module I've adopted. I've got everything up and running config wise and the pages are getting run through AxKit just fine. The first two tests simply consist of a set-value page which uses Apache::Session::File to store a value, and a get-value page that confirms the value is returned. Of course the get-value test, test 2, fails because Apache::TestRequest is ignore the sessionid cookie [or all cookies really]. I have LWP installed and I've tried a few different encantations using -cookie_jar and HTTPCookie without any luck. Is there a Tutorial or examples somwhere that cover dealing with sessions within Apache::TestRequest? I guess the silence means that no one has used it with cookies. I suppose that you could fix it to work with cookies though. But I could be wrong and it already works but not documented. there is a lot of such code in there. -- __ 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: Apache-TestItSelf
Stas Bekman wrote: Before we can try to improve the problems with A-T config issues, we need a test suite. Since until now, every fix was breaking 10 other things. So I've started working on one. It's probably going to change a lot, but I have a working prototype. In order to use it apply the attached patch against Apache-Test/ and run: I take the lack of comments (3 weeks) as an agreement and will proceed with the proposed layout/approach and commit things when I get them a bit more polished. -- __ 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: Apache::TestRequest + Cookies
Christopher H. Laco wrote: Thanks. I'll give that a whirl tonight. I finally got the hack approach working by calling $apacheRequestResponse-headers(Set-Cookie) and passing that result right back into the [scantily mentioned] second param of Apache::TestRequest::GET 'url', headername = headervalue if you could also contribute the cookie test that would be handy too. -- __ 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
is it safe to enable Lockfile for all mpms across all apache generations?
It looks like some poeple have a problem with LockFile directive being compiled to a hardcoded value. The problem: [Tue Nov 02 17:16:22 2004] [emerg] (13)Permission denied: Couldn't create accept lock Is it safe to set LockFile for all mpms? For apache 1.3? If yes, I'm going to add it to test framework globally. Thank you! p.s. the problem reported and the diagnose made in this thread: http://thread.gmane.org/gmane.comp.apache.mod-perl/15547 -- __ 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: Apache::TestRequest + Cookies
Christopher H. Laco wrote: if you could also contribute the cookie test that would be handy too. I'm feeling a bit dense at the moment. To the list, or to the forthcoming [self] test suite? I'm not sure I understand the request. Either way if you find how to use A-T to handle cookies or fix it to do so, it's be handy to add a new A-T tests (in addition to existing ones in Apache-Test/t/) so we don't break this feature in the future, which is easily possible sans having a test. Plus it'll be great to have this documented... if you don't have the time to send a proper patch, feel free to send some blurb+example(s) here and I'll adopt it for the docs. -- __ 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: 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
[EMAIL PROTECTED] wrote: Author: jorton Date: Fri Nov 19 02:27:41 2004 New Revision: 105803 Removed: httpd/test/trunk/perl-framework/.cvsignore httpd/test/trunk/perl-framework/Apache-Test/.cvsignore httpd/test/trunk/perl-framework/Apache-Test/lib/Apache/.cvsignore [...] Log: Remove .cvsignore files what's the replacement for .cvsignore under svn? I can't see where the data in .cvsignore has migrated to. -- __ 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: 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
Joe Orton wrote: On Fri, Nov 19, 2004 at 03:23:46PM -0500, Stas Bekman wrote: Geoffrey Young wrote: 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 Yes, but how do I see the change? I've seen Joe removing .cvsignore files. I have no idea whether he has added the properties for each of the removed files or not. The changes should be emailed no? 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? When a propchange is committed a notification mail *will* be sent, but the post-commit script won't actually tell you the before-and-after in that case, it seems. I'm not sure whether that's a deficiency of the script being used or of SVN itself. You mean it only tells that there was a change, but not what was the change? if so who should be asked to fix that? -- __ 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: [NOTICE] Subversion conversion
Geoffrey Young wrote: Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I thought we had discussed httpd-test a while back - something like we couldn't migrate httpd-test to subversion until modperl-2.0 was also migrated to subversion, since a mp2 checkout includes part httpd-test/perl-framework/Apache-Test. personally, I'd rather use subversion for everything, and I can't recall the specifics of the issue, but I thought I'd bring it up in case it makes sense to somebody :) It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into modperl-2.0 check out. As long as this is all done at once there should be no problem. None of these projects had any branching so it shouldn't be a problem. But I've next to zero experience with subversion, so I'm not volunteering to do that. Also it's important to keep a frozen version of the cvs, so one could still get cvs diffs for those modified checkouts that we have, for work in progress. So first modperl-docs needs to be moved, then httpd-test, then modperl-2.0, I believe. -- __ 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: [NOTICE] Subversion conversion
Justin Erenkrantz wrote: On Sun, Nov 14, 2004 at 03:29:07PM -0500, Stas Bekman wrote: It's just that someone needs to simultaneously move modperl-2.0 to subversion too. And modperl-docs too, since they are checked out into There's no reason we can't do the mp conversion today as well. Stop by at the Hackathon and we can sort this out. -- justin I'm not at ApacheCon. Gozer? Geoff? -- __ 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: time for Apache-Test 1.16
Geoffrey Young wrote: 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 :) +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
Apache-TestItSelf
Before we can try to improve the problems with A-T config issues, we need
a test suite. Since until now, every fix was breaking 10 other things.
So I've started working on one. It's probably going to change a lot, but I
have a working prototype. In order to use it apply the attached patch
against Apache-Test/ and run:
perl Makefile.PL
now the t_c/TEST script runs the tests against Apache-Test, modperl-2.0,
other CPAN modules.
All you need to do is to supply a config file for each group of the above
tests. For example:
I run this against Apache-Test:
t_c/TEST -v -base ~/work/modules/Apache-VMonitor-2.0 -config
~/.apache-test/apache_test_config.pm
where ~/.apache-test/apache_test_config.pm contains:
@Apache::TestItSelf::Configs = (
{
apxs_exec = '/home/stas/httpd/prefork/bin/apxs',
httpd_exec= '/home/stas/httpd/prefork/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'prefork',
makepl_arg= '-libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
},
{
apxs_exec = '/home/stas/httpd/worker/bin/apxs',
httpd_exec= '/home/stas/httpd/worker/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'worker',
makepl_arg= '-libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
},
);
1;
Next I run the same tests against Apache-VMonitor-2.0 (or any other module
that deployes A-T):
t_c/TEST -v -base ~/work/modules/Apache-VMonitor-2.0 -config
~/.apache-test/apache2_modules_testitself_config.pm
where ~/.apache-test/apache2_modules_testitself_config.pm is:
@Apache::TestItSelf::Configs = (
{
apxs_exec = '/home/stas/httpd/prefork/bin/apxs',
httpd_exec= '/home/stas/httpd/prefork/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'prefork',
makepl_arg= 'MOD_PERL=2 -libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
test_verbose = 0,
},
{
apxs_exec = '/home/stas/httpd/worker/bin/apxs',
httpd_exec= '/home/stas/httpd/worker/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'worker',
makepl_arg= 'MOD_PERL=2 -libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
test_verbose = 0,
},
);
1;
and finally modperl-2.0:
t_c/TEST -v -base ~/apache.org/mp2-cvs -config
~/.apache-test/modperl2_testitself_config.pm t_c/httpd_arg.t
where ~/.apache-test/modperl2_testitself_config.pm
@Apache::TestItSelf::Configs = (
{
apxs_exec = '/home/stas/httpd/prefork/bin/apxs',
httpd_exec= '/home/stas/httpd/prefork/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'prefork',
makepl_arg= 'MP_APXS=/home/stas/httpd/prefork/bin/apxs
MP_INST_APACHE2=1 MP_MAINTAINER=1',
timeout = 900,
},
{
apxs_exec = '/home/stas/httpd/worker/bin/apxs',
httpd_exec= '/home/stas/httpd/worker/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'worker',
makepl_arg= 'MP_APXS=/home/stas/httpd/worker/bin/apxs
MP_INST_APACHE2=1 MP_MAINTAINER=1',
timeout = 900,
},
);
1;
t_c/interactive.t can't be run with modperl-2.0. I'm going to add the skip
mechanism via the config files.
(The only practical problem I see at the moment is that things are pretty
slow... but it's better than no tests suite at all).
The config files are going to evolve and the key names will change too...
At the moment there are only 2 test files, more will be added as things
evolve.
Comments are welcome. I'd like to start committing things after some
additional polish if there are no objections.
--
__
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
Index: Makefile.PL
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/Makefile.PL,v
retrieving revision 1.24
diff -u -u -r1.24 Makefile.PL
--- Makefile.PL 27 Sep 2004 04
Re: Apache-TestItSelf
I run this against Apache-Test:
t_c/TEST -v -base ~/work/modules/Apache-VMonitor-2.0 -config
~/.apache-test/apache_test_config.pm
Sorry, that should have been:
t_c/TEST -v -base ~/apache.org/Apache-Test -config
~/.apache-test/apache_test_config.pm
where ~/.apache-test/apache_test_config.pm contains:
@Apache::TestItSelf::Configs = (
{
apxs_exec = '/home/stas/httpd/prefork/bin/apxs',
httpd_exec= '/home/stas/httpd/prefork/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'prefork',
makepl_arg= '-libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
},
{
apxs_exec = '/home/stas/httpd/worker/bin/apxs',
httpd_exec= '/home/stas/httpd/worker/bin/httpd',
perl_exec = '/home/stas/perl/5.8.5-ithread/bin/perl5.8.5',
mp_gen= 2.0,
httpd_gen = 2.0,
httpd_version = 'Apache/2.0.53-dev',
httpd_mpm = 'worker',
makepl_arg= '-libmodperl mod_perl-5.8.5-ithread.so',
timeout = 200,
},
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestMM.pm
[EMAIL PROTECTED] wrote:
geoff 2004/11/03 12:37:22
Modified:perl-framework/Apache-Test/lib/Apache TestMM.pm
Log:
reverting to 1.41 - apparently the conditional assignment borks win32
return $preamble . 'EOF' . $cover;
-TEST_VERBOSE ?= 0
+TEST_VERBOSE = 0
why not if (WIN32) {} then?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Geoffrey Young wrote: [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 :) That's exactly right. you did the right thing. I'm still relying on a anonymous friendly neighbour somewhere on the same block to get my oxygen. One day we will be able to get online in a matter of seconds... -- __ 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: Fix: Apache::TestRequest::redirect_ok
David Wheeler wrote: On Oct 19, 2004, at 11:23 PM, David Wheeler wrote: But please wait before mp2/Apache-Test are released tomorrow, since were are in the code freeze section as both have RC posted, and in theory no code should be committed (docs are OK). Will do. Committed. that was quick :) thanks David! -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm
[EMAIL PROTECTED] wrote:
jorton 2004/10/20 06:42:07
Modified:perl-framework/Apache-Test/lib/Apache Test.pm
Log:
Add the need_php4 export.
It's of little value if it's not documented, especially when the rest is.
Joe, please see the pod at the end of that file (search for need_php).
Revision ChangesPath
1.106 +1 -1 httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm
Index: Test.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/Test.pm,v
retrieving revision 1.105
retrieving revision 1.106
diff -d -w -u -r1.105 -r1.106
--- Test.pm 20 Oct 2004 13:38:15 - 1.105
+++ Test.pm 20 Oct 2004 13:42:07 - 1.106
@@ -27,7 +27,7 @@
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 need_ssl);
+ need_php need_php4 need_ssl);
my @have = map { (my $need = $_) =~ s/need/have/; $need } @need;
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm
Joe Orton wrote: On Wed, Oct 20, 2004 at 11:37:45PM -0400, Stas Bekman wrote: [EMAIL PROTECTED] wrote: jorton 2004/10/20 06:42:07 Modified:perl-framework/Apache-Test/lib/Apache Test.pm Log: Add the need_php4 export. It's of little value if it's not documented, especially when the rest is. Joe, please see the pod at the end of that file (search for need_php). I documented it in the commit before :) Opps, my apologies, I've missed it. Thanks Joe. -- __ 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: Fix: Apache::TestRequest::redirect_ok
David Wheeler wrote:
On Oct 19, 2004, at 2:48 PM, Stas Bekman wrote:
In which case, can you please review Boris' patch and commit it if you
think it's good? As I haven't coded and haven't used much this
feature, I'd rather let somebody who is more familiar with it do the
decision. If it breaks something, we can always fix that later. And of
course when changing something it's a good idea to add a new test
which exercises that fix. Thanks.
I hate this code.
I think that the original idea was that, if LWP was installed, then
redirects from POST were supported. Otherwise, they were not, as
Apache::TestRequest didn't have the code to handle it. (Why? I have no
idea.)
If that's the case, then Boris' code makes decent sense, beucause the
call to can('SUPER::redirect_ok') will return a code reference if LWP is
installed and TestRequest inherits from it. Otherwise, it decides for
itself. So to keep things consistent, I would actually do this:
--- TestRequest.pm.~1.100.~Tue Oct 19 18:08:08 2004
+++ TestRequest.pmTue Oct 19 18:09:24 2004
@@ -199,8 +199,9 @@
$RedirectOK = 1;
sub redirect_ok {
-my($self, $request) = @_;
-return 0 if $request-method eq 'POST';
+my $self = shift;
+return $self-SUPER::redirect_ok(@_) if $have_lwp;
+return 0 if shift-method eq 'POST';
$RedirectOK;
}
that looks better than goto :)
But this means that POST redirects will work if LWP is installed and
won't if it is not. If it's true that, without LWP, TestRequest *cannot*
handle redirect on POST requests, then this is how it should be.
I believe that it can't. I think TestRequest doesn't try to provide a
replacement for lwp. It's a very basic client which should be used only
for very basic tests. One should add need_lwp in the plan() call for more
complicated cases.
--
__
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
