Re: [RELEASE CANDIDATE] Apache-Test-1.14
On Mon, Oct 11, 2004 at 09:00:36AM -0700, David Wheeler wrote: > On Oct 11, 2004, at 6:36 AM, Geoffrey Young wrote: > > >a release candidate for Apache-Test 1.14 is now available. > > > > http://perl.apache.org/~geoff/Apache-Test-1.14-dev.tar.gz > > All tests pass for me, and my module that uses Apache::TestMB continues > to work nicely with this version installed. Ditto. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::TestMB error
On Fri, Sep 10, 2004 at 04:07:35PM -0700, David Wheeler wrote: > >I'm getting an error when trying to use Stas' template[1] with your > >module. Basically, the filter_args() method is generating an error. I > >am > >calling it like this: > > > > Apache::TestMB::filter_args(); > > You don't need to do that. Apache::TestMB does it for you. Nice. > >My build seems to work fine with this method commented out. However, > >I'm > >wondering if this is an oversight in the A::TestMB module or an > >incompatibility. > > No, not an oversight. I just made its interface simpler and more OO > than Apache::TestMM's. I'm liking Module::Build more and more ;). > Scroll down a bit more to see the Build.PL example I added. Oops, I hadn't realized that you updated that page after you released Apache::TestMB. Thanks for your work on integrating M::B with Apache::Test. William -- Knowmad Services Inc. http://www.knowmad.com
Apache::TestMB error
Hi David, I'm getting an error when trying to use Stas' template[1] with your module. Basically, the filter_args() method is generating an error. I am calling it like this: Apache::TestMB::filter_args(); My build seems to work fine with this method commented out. However, I'm wondering if this is an oversight in the A::TestMB module or an incompatibility. Thanks, William [1] http://perl.apache.org/docs/general/testing/testing.html#Basic_Testing_Environment (you'll need to scroll down a bit til you get to the Makefile.PL example) -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Wed, Aug 25, 2004 at 05:59:16PM -0700, Stas Bekman wrote: > Heh, it's so much easier when you have a reproducable case to work on. Believe me, I know; I ask my clients for reproducible cases all the time. I'm starting to learn some tricks for tracking down problems like this one. Hopefully my reports will be better in the future. > Here is the reduced version of your test independent of A-T: Ahh, now I see. I'll be interested to hear the outcome from the p5p list. > Meanwhile I've committed another workaround, please either use the cvs > version or apply this patch and let me know whether the problem is still > there: This version works fine for me with the test cases I submitted. Glad to have that issue out of the way now . Thanks! William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Tue, Aug 24, 2004 at 01:35:48PM -0400, William McKee wrote: > > was there supposed to be an attachment or something? > > Dangit! Let's try that again... OK, something funny is going on. My attachments seem to be getting stripped. I'm going to inline the code in this email. William --- ## FILE: statement_not_reached_OK.t #!/usr/bin/perl use strict; no strict 'refs'; use warnings; use Test::More; plan tests => 1; use Apache::TestUtil; use Apache::TestRequest; # This is OK use CGI::Carp; ok 1; ## FILE: statement_not_reached.t #!/usr/bin/perl use strict; no strict 'refs'; use warnings; use Test::More; plan tests => 1; # Calling CGI::Carp before loading Apache::* fails use CGI::Carp; use Apache::TestUtil; use Apache::TestRequest; ok 1; -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Mon, Aug 23, 2004 at 08:20:39PM -0700, Stas Bekman wrote: > >OK, I have a reproducible set of tests which work the same on Win* and > >Linux. The problem has to do with bringing CGI::Carp into play. Here are > >two additional tests--one works and the other fails. I hope this will > >help you to resolve the "Statement unlikely to be reached" errors. > > > >Apparently under Linux, my test suite was working because I was loading > >CGI::Carp somewhere along the way. This wasn't the case in Windows. > > was there supposed to be an attachment or something? Dangit! Let's try that again... Wm -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Mon, Aug 23, 2004 at 03:09:26PM -0400, William McKee wrote: > I find it interesting that the default testsuite doesn't run into this > error but that my tests do. I'll try to create a test that causes the > error and send it to the list. OK, I have a reproducible set of tests which work the same on Win* and Linux. The problem has to do with bringing CGI::Carp into play. Here are two additional tests--one works and the other fails. I hope this will help you to resolve the "Statement unlikely to be reached" errors. Apparently under Linux, my test suite was working because I was loading CGI::Carp somewhere along the way. This wasn't the case in Windows. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Mon, Aug 23, 2004 at 11:47:21AM -0700, Stas Bekman wrote: > Well, I tried to fix it some time ago, but w/o being able to reproduce it > I wasn't very successful. If you have ideas to what could be the problem, > please let us know/send a patch. I find it interesting that the default testsuite doesn't run into this error but that my tests do. I'll try to create a test that causes the error and send it to the list. > It's interesting that no other win32 user > has complained about this. Randy, have you possibly seen this? And what version of Perl/Win* are you using? I'm on WinXP with ActiveState Perl Build 809. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Fri, Aug 20, 2004 at 01:56:05PM -0700, Stas Bekman wrote: > >>So all the problems you have reported before are now resolved, William? > > > > > >I knew you were going to ask me that ! It's not necessarily the case. > >I did not do a complete test under Windows using my test suite; I just > >ran the basic tests that come with A::T. I'll try to get to that over > >the weekend and let you know. > > Sure. Take your time, William. > > I think at least the problem of the endless interactive config loop has > been solved now. Yes, I'm not seeing that behavior (although I might be specifying the httpd path by habit when I run `perl Makefile.PL`). OK, I tested the new release with my full test suite and am still getting "Statement unlikely to be reached" failures in TestRun.pm at lines 643 and 747. I'm simply patching this file which works for my needs. It seems this is a perl issue under Win32; I'm still running 5.8.3 on that platform. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Fri, Aug 20, 2004 at 11:08:33AM -0700, Stas Bekman wrote: > >It's working fine for me under both Linux and Windows. > > Thanks! > > So all the problems you have reported before are now resolved, William? I knew you were going to ask me that ! It's not necessarily the case. I did not do a complete test under Windows using my test suite; I just ran the basic tests that come with A::T. I'll try to get to that over the weekend and let you know. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Thu, Aug 19, 2004 at 12:17:37PM -0700, Stas Bekman wrote: > You can download the release candidate from here: > http://www.apache.org/~stas/Apache-Test-1.13-dev.tar.gz > > If there are no problems reported Apache-Test 1.13 will be > released tomorrow. It's working fine for me under both Linux and Windows. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Infinite looping in self-configuration mode (was Re: [RELEASE CANDIDATE] Apache-Test-1.06)
On Fri, Jul 16, 2004 at 05:27:47PM -0700, Stas Bekman wrote: > >Finally getting back to this thread Even with the latest Apache-Test > >from CVS, I'm still getting the infinite looping when A::T tries to do > >it's self-configuration. > > Sorry for taking so long to followup, William. It's hard to guess what > could the problem be, when I can't reproduce it. Hey Stas, Thnnks for getting back to me. I was hoping the error message regarding the Apache revision may give you some hints. It doesn't mean much to me. > How about the current cvs? Do you still get it? I haven't tried it since my last email and don't have much spare time at the moment. I suspect I'll run across it again when the next A::T release comes out if it's not fixed . I'll keep my eyes open. Thanks, WIlliam -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T :withtestmore
On Tue, Jul 13, 2004 at 09:12:32AM -0400, Geoffrey Young wrote: > the limitation here is that perl package namespaces cannot contain hyphens, > which is not specifically mentioned but can be inferred from perlvar.pod, > "Technical Note on the Syntax of Variable Names". Thanks for the explanation. Makes perfect sense now. William -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T :withtestmore
On Sun, Jul 11, 2004 at 11:29:07PM -0400, Geoffrey Young wrote: > > This makes me think that there may be a problem in the bug testing > > framework itself when used in conjunction with the -testmore action. > > I don't think so :) I appreciate your confidence . > > I > > don't see a require statement in Bug.pm so am at a loss to say why this > > would be failing. I tried changing the name of bug-tm.pm to bug_tm.pm in > > case the hypen was a problem; it didn't help. Any other ideas? > > I changed it to bugpm.pm (and changed the package name) and it worked fine. Actually, changing it to bug_tm.pm works. I had forgotten to change the package name when I retested :(. So hyphens in response tests are a bad thing? At any rate, my system now appears to support Test::More in response tests. Yeah! Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T :withtestmore
On Sat, Jul 10, 2004 at 03:10:11PM -0400, Geoffrey Young wrote: > I couldn't get that patch to apply to current cvs. Maybe that's my problem. I applied the patch to the Test.pm from 1.12 release. > > However, I'm still not getting the expected > > results. I suppose that could be the fuzz factor you mentioned but put > > together a new version of my test package in case you want to see if I'm > > just doing something stupid[1]. > > well, I get the same results, and I can't see offhand what you are doing > wrong. but I started a tarball from scratch and was able to get it working > with no problem at all. so, try this tarball > > http://perl.apache.org/~geoff/testmore-geoff.tar.gz Thanks. This works for me too so I guess the patch works against the 1.12 version. I checked the error logs and found the following difference in mine: [Sun Jul 11 16:31:59 2004] [notice] Accept mutex: sysvsem (Default: sysvsem) Warning: Use of "require" without parentheses is ambiguous at (eval 12) line 1. [Sun Jul 11 16:32:01 2004] [error] Undefined subroutine &TestApache::My::Bug::bug-tm::handler called.\n [Sun Jul 11 16:32:01 2004] [info] removed PID file /home/william/perl/bug-reporting-skeleton-mp1/t/logs/httpd.pid (pid=2537) Do you see this error when you run my package? This makes me think that there may be a problem in the bug testing framework itself when used in conjunction with the -testmore action. I don't see a require statement in Bug.pm so am at a loss to say why this would be failing. I tried changing the name of bug-tm.pm to bug_tm.pm in case the hypen was a problem; it didn't help. Any other ideas? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T :withtestmore
Hi Geoff, Thanks for the info and the patch. I applied the patch without a problem and then went to install the developer release of T::M. Dost my eyes decieve me or does that say it was last updated on November 11, 2002? That's a long release cycle. At any rate, I installed the latest copy of T::M and read your directions in the patch. However, I'm still not getting the expected results. I suppose that could be the fuzz factor you mentioned but put together a new version of my test package in case you want to see if I'm just doing something stupid[1]. I understand that you can't release this code until T::M is released but considering that T::M may be a bit longer baking, an additional caveat in the A::T pod would be useful in case T::M doesn't get released before the next release of A::T. I've attached a patch against the pristine version of 1.12. Thanks, William [1] http://knowmad.com/~william/testmore-bug.tar.gz -- Knowmad Services Inc. http://www.knowmad.com --- Test.pm.orig2004-06-24 09:18:31.0 -0400 +++ Test.pm.wlm 2004-07-10 12:39:47.0 -0400 @@ -763,7 +763,7 @@ =head1 Test::More Integration There are a few caveats if you want to use I with -I instead of the default I backend. The first is +I instead of the default I backend. The first is that you cannot use it in response tests (yet). The second is that I requires you to use its own C function and not the one that ships with I. I also defines C and C functions that are different, and
Re: A::T :withtestmore
On Fri, Jul 09, 2004 at 07:27:28PM -0400, William McKee wrote: > Can anyone confirm/deny this behavior? In the meantime, I'll try to put > together a test script. I've been able to reproduce the error using Geoff's skeleton. I almost thought I had it fixed, but it's a bit beyond my knowledge and skills (esp. on a Friday evening!). The problem appears to be due to headers not being sent when using Test::More. I found the code in Apache::Test which initializes a handler when `plan $r, tests => 10` is called. This sends a http header. I copied it into my bug-tm.pm response handler (t/response/TestApache/My/Bug) but am still getting 500 errors with nothing in the error_log. The test is available at my website[1]. The default version will work! I wanted to show that using Apache::Test normally in a response handler is working. You'll need to change the name of t/response/TestApache/My/Bug/bug-tm.pm.off so that it gets tested. In my tests, doing this causes both bug.t and bug-tm.t to fail. Thanks, William [1] http://knowmad.com/~william/testmore-bug.tar.gz -- Knowmad Services Inc. http://www.knowmad.com
A::T :withtestmore
Hi all, I'm having some problems getting Apache::Test working with Test::More for my response tests. It's working fine in my request tests but my server is silently failing with the following output: server localhost:8529 started t/apache/knowmad/mailform/cgiapp_setuprequest has failed (the response code was: 500) see t/logs/error_log for more details Checking the logs only shows the server starting and stopping. If I change the test count, I get messages such as: # Looks like you planned 6 tests but only ran 1 This makes me think the handler is running but output is not getting returned to the request script. If I switch back to the default A::T format, the tests pass fine. Can anyone confirm/deny this behavior? In the meantime, I'll try to put together a test script. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::TestMB returns 1
On Mon, Jul 05, 2004 at 11:09:47AM -0700, David Wheeler wrote: > >When I try running generate_smoke, I get the following output: Now I'm doing it! That should have been generate_script. > Oh, sorry, it's generate_test_script(). OK, that worked. Why is it named differently from the format used by Apache::TestMM? Nevermind, I see your follow-up message. That works for me! Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Apache::TestMB returns 1
On Fri, Jul 02, 2004 at 09:51:32AM -0700, David Wheeler wrote:
> Oh, quite right. My fault. This patch fixes the docs:
>
> --- TestMB.pm.~1.2.~ Fri Jun 25 18:55:53 2004
> +++ TestMB.pm Fri Jul 2 09:49:40 2004
> @@ -180,7 +180,7 @@
>my $build_pkg = eval { require Apache::TestMB }
>? 'Apache::TestMB' : 'Module::Build';
>
> - my $build = $build_pkg->new(
> + $build_pkg->new(
>module_name => 'My::Module',
>)->create_build_script;
Actually I'd prefer the following format:
my $build = $build_pkg->new (...);
$build->create_build_script;
The reason is that this shows how to work with a build object. This is
necessary if you want to use methods such as generate_script.
> I don't know what's in the SMOKE script, since I never used it.
I copied it verbatim from the testing page[1] on the mod_perl website.
It's a handy utility!
> You can use Apache::TestMB->generate_script, however; will that work?
When I try running generate_smoke, I get the following output:
Can't locate object method "generate_script" via package "Apache::TestMB" at
Build.PL line 62.
> It should do pretty much the same things as
> Apache::TestMM::generate_smoke().
Should that be Apache::TestMM::generate_script()?
Regards,
William
[1]
http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
--
Knowmad Services Inc.
http://www.knowmad.com
Apache::TestMB returns 1
Hi all, Sorry about that false start. Lemme try this again! As I was saying, David, thanks for adding support for Module::Build. I'm trying to replace one of my existing projects using the Apache::TestMB module. It works fine unless I try to do something with the return value from the examples: my $build = $build_pkg->new( module_name => 'My::Module', dist_version => '0.1.0', )->create_build_script; I was getting 1 back in $build. In preparing this email, I realized that the results of new() are immediately calling create_build_script() which is returning 1. Now, that I have that issue figured out, I'm trying to use the build object to generate a SMOKE script. The TEST script seems to be automatically built. The generate_script() method that I was using with A::TestMM is not available. Is there another way I should be generating this script? William -- Knowmad Services Inc. http://www.knowmad.com
Apache::TestMB returns 1
Hi David, Thanks for your efforts in adding support -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T - Running tests against multiple servers
On Fri, Jun 25, 2004 at 01:39:50PM +0300, Stas Bekman wrote: > You can do that easily: > > 1) start the server: > t/TEST -start > > 2) start as many clients as you want (e.g. 3 clients): > > t/TEST -run [tests] & > t/TEST -run [tests] & > t/TEST -run [tests] & Thanks Stas! I was finally able to get my tests to fail as I was seeing in the production server. That's a nice recipe for catching race conditions. William -- Knowmad Services Inc. http://www.knowmad.com
A::T - Running tests against multiple servers
Hi, Here's an interesting problem I've come across. I have an application that is occassionally retrieving duplicate data from a BerkeleyDB. I've written a couple tests which, so far, cannot duplicate the problem (one using a direct database interface and another using A::T). This has led me to believe that the problem must result from a different Apache process interfering with an already running process (there is a gap between reading the record and deleting it whereby another process could come in and read the record again). Thus, I need to get A::T to run several clients in synch against my application in order to hound out this error. Is there a way to do this with A::T or should I be using another utility? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.12
On Thu, Jun 24, 2004 at 02:35:39PM -0400, William McKee wrote: > On Thu, Jun 24, 2004 at 09:30:29AM -0400, Geoffrey Young wrote: > > please take the time to excercise the candidate through all your existing > > applications that use Apache-Test and report back successes or failures. > > Looks good for me. Ooops, spoke too soon again. I'm still having problems with TestRun.pm in Windows XP. Here's the output: [Thu Jun 24 17:21:56 2004] [error] [client 127.0.0.1] Statement unlikely to be reached at c:\TigerCub\perl5\5.8.3/Apache/TestRun.pm line 669. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/TestServer.pm line 25. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/TestServer.pm line 25. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/TestConfig.pm line 51. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/TestConfig.pm line 51. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/Test.pm line 23. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/Test.pm line 23. Compilation failed in require at C:\TigerCub\t\response/Xfer/_get_next_valid_candidate.pm line 11. BEGIN failed--compilation aborted at C:\TigerCub\t\response/Xfer/_get_next_valid_candidate.pm line 11. Compilation failed in require at (eval 6) line 3. Commenting out lines 669 and 1696 make it work fine. I remember having this discussion a few months back but did not find a solution. Apparently it is still an issue. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.12
On Thu, Jun 24, 2004 at 09:30:29AM -0400, Geoffrey Young wrote: > please take the time to excercise the candidate through all your existing > applications that use Apache-Test and report back successes or failures. Looks good for me. William -- Knowmad Services Inc. http://www.knowmad.com
Infinite looping in self-configuration mode (was Re: [RELEASE CANDIDATE] Apache-Test-1.06)
On Mon, May 24, 2004 at 11:19:02AM -0700, Stas Bekman wrote: > I'm not sure, but you could run both with tracing on -trace=debug or > APACHE_TEST_TRACE_LEVEL=debug and then compare the logs. Could be that in > one case it finds a global httpd.conf but not in the other? Hi Stas, Finally getting back to this thread Even with the latest Apache-Test from CVS, I'm still getting the infinite looping when A::T tries to do it's self-configuration. In my estimation, the following line is the significant difference between the two traces: can't figure out Apache revision, from string: '', using a non-existing revision 0 That error happens several times in guess-mode but is never seen in the successful run. Furthermore, as you can see from the successful trace, my path to EAPI_MM_CORE_PATH is indeed relative -- 'logs/httpd.mm'. William --- Here's the output with trace from an unsuccessful make test: /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean setting ulimit to allow core files ulimit -c unlimited; /usr/local/bin/perl /home/william/perl/modperl-2.0/Apache-Test/t/TEST -clean trying to load custom config data loading custom config path '/home/william/.apache-test/Apache/TestConfigData.pm' can't figure out Apache revision, from string: '', using a non-existing revision 0 can't figure out Apache revision, from string: '', using a non-existing revision 0 unlink /home/william/perl/modperl-2.0/Apache-Test/t/logs/apache_runtime_status.sem: No such file or directory APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 setting ulimit to allow core files ulimit -c unlimited; /usr/local/bin/perl /home/william/perl/modperl-2.0/Apache-Test/t/TEST -bugreport -verbose=0 trying to load custom config data loading custom config path '/home/william/.apache-test/Apache/TestConfigData.pm' can't figure out Apache revision, from string: '', using a non-existing revision 0 generating conf/mime.types generating htdocs/index.html Will 'Include' /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf config file generating conf/extra.conf from /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf.in generating conf/httpd.conf generating conf/apache_test_config.pm saving config data to apache_test_config.pm trying to load custom config data can't figure out Apache revision, from string: '', using a non-existing revision 0 unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/mime.types unlink /home/william/perl/modperl-2.0/Apache-Test/t/htdocs/index.html unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/apache_test_config.pm unlink /home/william/perl/modperl-2.0/Apache-Test/t/logs/apache_runtime_status.sem: No such file or directory unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/httpd.conf unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf rmdir /home/william/perl/modperl-2.0/Apache-Test/t/logs rmdir /home/william/perl/modperl-2.0/Apache-Test/t/htdocs We are now going to configure the Apache-Test framework. This configuration process needs to be done only once. . And here's the output from a successful test (done by passing -httpd path to perl Makefile.PL command): /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean setting ulimit to allow core files ulimit -c unlimited; /usr/local/bin/perl /home/william/perl/modperl-2.0/Apache-Test/t/TEST -clean trying to load custom config data loading custom config path '/home/william/.apache-test/Apache/TestConfigData.pm' isolated httpd_info VERSION = Apache/1.3.31 (Unix) isolated httpd_info BUILT = May 28 2004 18:55:40 isolated httpd_info MODULE_MAGIC_NUMBER = 19990320:16 isolated httpd_defines EAPI = 1 isolated httpd_defines EAPI_MM = 1 isolated httpd_defines EAPI_MM_CORE_PATH = logs/httpd.mm isolated httpd_defines HAVE_MMAP = 1 isolated httpd_defines HAVE_SHMGET = 1 isolated httpd_defines USE_SHMGET_SCOREBOARD = 1 isolated httpd_defines USE_MMAP_FILES = 1 isolated httpd_defines HAVE_FCNTL_SERIALIZED_ACCEPT = 1 isolated httpd_defines HAVE_SYSVSEM_SERIALIZED_ACCEPT = 1 isolated httpd_defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT = 1 isolated httpd_defines DYNAMIC_MODULE_LIMIT = 64 isolated httpd_defines HARD_SERVER_LIMIT = 256 isolated httpd_defines HTTPD_ROOT = /usr/local/apache isolated httpd_defines SUEXEC_BIN = /usr/local/apache/bin/suexec isolated httpd_defines DEFAULT_PIDLOG = logs/httpd.pid isolated httpd_defines DEFAULT_SCOREBOARD = logs/httpd.scoreboard isolated httpd_defines DEFAULT_LOCKFILE = logs/httpd.lock isolated httpd_defines DEFAULT_ERRORLOG = logs/error_log isolated httpd_defines TYPES_CONFIG_FILE = conf/mime.types isolated httpd_defines SERVER_CONFIG_FILE = conf/httpd.conf isolated httpd_defines ACCESS_CONFIG_FILE = conf
Re: [RELEASE CANDIDATE] Apache-Test-1.06
Thanks for the info Stas and Joe. I will try rebuilding with Joe's suggestion. However, I'm curious why things work just fine when I run the tests and pass in the path to httpd. For example: t/TEST -httpd /usr/local/apache/bin/httpd William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Fri, May 21, 2004 at 01:43:49PM -0700, Stas Bekman wrote: > So does this file exist and executable? /usr/local/apache/bin/httpd? any > symlinks involved? I fail to reproduce it on my machine. Yes, it exists and is executable. I wonder if there is a permissions problem That appears to be a problem. If I try to run it as a normal user (which is how I was testing), I get the following error: Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.6895") failed Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No such file or directory Of course, that is using the default configuration file which is probably the reason its trying to write to /usr/local/apache/logs. However, if I go to the t/conf directory and try the following command: /usr/local/apache/bin/httpd -f httpd.conf I'm getting similar output: Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.7012") failed Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No such file or directory HTH, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Fri, May 21, 2004 at 10:38:59AM -0700, Stas Bekman wrote:
> Thanks William, what do you have inside:
> /home/william/.apache-test/Apache/TestConfigData.pm
package Apache::TestConfigData;
use strict;
use warnings;
$Apache::TestConfigData::vars = {
'httpd' => '/usr/local/apache/bin/httpd',
};
1;
=head1 NAME
Apache::TestConfigData - Configuration file for Apache::Test
=cut
--
Knowmad Services Inc.
http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Thu, May 20, 2004 at 08:29:33PM -0700, Stas Bekman wrote: > Please show us the verbose trace: > > t/TEST -trace=debug > > including the part where you completed the interactive questions, and it > brought you back to interactive config again. Got the latest version from CVS again and this time received the following message when running `perl Makefile.PL': generating script t/TEST Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. Writing Makefile for Apache::Test The trace is attached. Note that this test was performed on a different system which apparently did not have the location of my server cached so I had to type it in. I still saw the same looping behavior. All tests pass if I run `t/TEST -httpd /usr/local/apache/bin/httpd'. William -- Knowmad Services Inc. http://www.knowmad.com [EMAIL PROTECTED]:~/perl/modperl-2.0/Apache-Test$ t/TEST -trace=debug setting ulimit to allow core files ulimit -c unlimited; /usr/local/bin/perl /home/william/perl/modperl-2.0/Apache-Test/t/TEST -trace=debug trying to load custom config data loading custom config path '/home/william/.apache-test/Apache/TestConfigData.pm' can't figure out Apache revision, from string: '', using a non-existing revision 0 generating conf/mime.types generating htdocs/index.html Will 'Include' /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf config file generating conf/extra.conf from /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf.in generating conf/httpd.conf generating conf/apache_test_config.pm saving config data to apache_test_config.pm trying to load custom config data can't figure out Apache revision, from string: '', using a non-existing revision 0 unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/mime.types unlink /home/william/perl/modperl-2.0/Apache-Test/t/htdocs/index.html unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/apache_test_config.pm unlink /home/william/perl/modperl-2.0/Apache-Test/t/logs/apache_runtime_status.sem: No such file or directory unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/httpd.conf unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf rmdir /home/william/perl/modperl-2.0/Apache-Test/t/logs rmdir /home/william/perl/modperl-2.0/Apache-Test/t/htdocs We are now going to configure the Apache-Test framework. This configuration process needs to be done only once. First we need to know where the 'httpd' executable is located. If you have more than one Apache server is installed, make sure you supply the path to the one you are going to use for testing. You can always override this setting at run time via the '-httpd' option. For example: % t/TEST -httpd /path/to/alternative/httpd or via the environment variable APACHE_TEST_HTTPD. For example: % APACHE_TEST_HTTPD=/path/to/alternative/httpd t/TEST If for some reason you want to skip the test suite, type: skip Please provide a full path to 'httpd' executable: [] /usr/local/apache/bin/httpd Next we need to know where the 'apxs' script is located. This script provides a lot of information about the apache installation, and makes it easier to find things. However it's not available on all platforms, therefore it's optional. If you don't have it installed it's not a problem. Just press Enter. Notice that if you have Apache 2.x installed that script could be called as 'apxs2'. If you have more than one Apache server is installed, make sure you supply the path to the apxs script you are going to use for testing. You can always override this setting at run time via the '-apxs' option. For example: % t/TEST -apxs /path/to/alternative/apxs or via the environment variable APACHE_TEST_APXS. For example: % APACHE_TEST_APXS=/path/to/alternative/apxs t/TEST Please provide a full path to (optional) 'apxs' executable: [] Found custom config '/home/william/.apache-test/Apache/TestConfigData.pm' Writing custom config /home/william/.apache-test/Apache/TestConfigData.pm rerunning '/usr/local/bin/perl /home/william/perl/modperl-2.0/Apache-Test/t/TEST -trace=debug' with new config opts trying to load custom config data loading custom config path '/home/william/.apache-test/Apache/TestConfigData.pm' can't figure out Apache revision, from string: '', using a non-existing revision 0 generating conf/mime.types generating htdocs/index.html Will 'Include' /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf config file generating conf/extra.conf from /home/william/perl/modperl-2.0/Apache-Test/t/conf/extra.conf.in generating conf/httpd.conf generating conf/apache_test_config.pm saving config data to apache_test_config.pm trying to load custom config data can't figure out Apache revision, from string: '', using a non-existing revision 0 unlink /home/william/perl/modperl-2.0/Apache-Test/t/conf/mime.types unlink /home/william/perl/modperl-2.0/Apache-Test/t/ht
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Thu, May 20, 2004 at 08:00:36PM -0700, Stas Bekman wrote: > Make sure you don't have APACHE_TEST_NO_STICKY_PREFERENCES env var turned > on. That's exactly the problem I've raised in the other thread. Yeah, I read some of that thread though didn't follow the exact details. In any case, the only A::T related setting in my env is APACHE_TEST_COLOR. William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On Thu, May 20, 2004 at 11:58:36AM -0700, Stas Bekman wrote: > Thanks William, it was due to my recent change to remove the use of > revision 2 as a default. > I was able to reproduce it. Now fixed in cvs. Please confirm that it works > for you. Hi Stas, Actually I just pulled it out of CVS and am stuck in an endless configuration loop. It is giving me the following option: Please provide a full path to 'httpd' executable or choose from the following options: [1] /usr/local/apache/bin/httpd [1] If I hit enter, I'm returned back to this prompt. If I type in the address, it returns me back to the prompt. Any ideas or other tests you'd like me to run? William -- Knowmad Services Inc. http://www.knowmad.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
> please take the time to excercise the candidate through all your existing > applications that use Apache-Test and report back successes or failures. I had errors during testing which appear to be due to problems with the auto configuration. Here's the steps I used: perl Makefile.PL make make test Here's the output of the last command: /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/william/perl/Apache-Test-1.11-dev/t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /home/william/perl/Apache-Test-1.11-dev/t/TEST -bugreport -verbose=0 configure() has failed: Use of uninitialized value in subroutine entry at lib/Apache/TestConfig.pm line 1006. forcing Apache::TestConfig object save run 't/TEST -clean' to clean up before continuing +-+ | To report problems please refer to the SUPPORT file | +-+ make: *** [run_tests] Error 1 However everything works fine with the following command: perl Makefile.PL --httpd /usr/local/apache/bin/http make make test So, it appears that the configurator is not working for me. William -- Knowmad Services Inc. http://www.knowmad.com
Documentation question
Hi Stas, I'm working with an intern to create a graphical depiction of the A::T process. As we were working on this image, I came across the following lines in your testing doc on perl.apache.org[1]: -- The corresponding request part of the test is named just like the response part, using the following translation: $response_test =~ s|t/[^/]+/Test([^/]+)/(.*).pm$|t/\L$1\E/$2.t|; so for example t/response/TestApache/write.pm becomes: t/apache/write.t. -- Is this still accurate? My experience is that t/response/MyModule/mytest.pm becomes t/mymodule/mytest.t. Could you please resolve the differences for me? Thanks, William [1] http://perl.apache.org/docs/general/testing/testing.html#Developing_Response_only_Part_of_a_Test -- Knowmad Services Inc. http://www.knowmad.com
A::T Execution graphic
Hi all, My colleague and I have mocked up a graphic image to help depict the difference between request and response tests[1]. I'd appreciate your review and feedback of this image. It was built in OODraw if anyone wants a copy to hack on for themselves. Thanks, William [1] http://knowmad.com/~william/apache-test.jpg -- Knowmad Services Inc. http://www.knowmad.com
Odd script behavior in test environment
Hi folks, I've got a problem with a cgi script that is running under Apache::Test. Basically, the script runs fine on my production server but is failing in my test environment. The error message indicates that I'm missing a closing brace or bracket. I've checked the file and do not see a problem. In addition, perl -c returns syntax ok. The file has an __END__ token with a bit of old, commented code after it. The error message in my t/logs/error.log file puts the error at this line. Removing the __END__ token lets the script run in my test environment with no errors. This doesn't make any sense to me. Is A::T doing something to my test scripts that would be incompatible with an END token? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: t_cmp oddities
On Thu, Apr 08, 2004 at 10:57:58AM -0700, Stas Bekman wrote:
> and we ought to document this... hint, hint :)
I have attached a diff against v1.09 of the TestUtil.pm file. I'm not
sure if my explanation is entirely accurate. Please review and let me
know.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- TestUtil.pm.orig2004-04-09 11:58:59.0 -0400
+++ TestUtil.pm 2004-04-09 12:01:16.0 -0400
@@ -424,6 +424,11 @@
This function is exported by default.
+When comparing undef values, you must force the received value into an lvalue.
+You can do this with the following example:
+
+ t_cmp(undef, scalar foo(), "compare undef return value from foo()")
+
=item t_debug()
t_debug("testing feature foo");
Re: t_cmp oddities
On Thu, Apr 08, 2004 at 10:56:06AM -0700, Stas Bekman wrote:
> Yes, I'm aware of this problem too. I sometimes use a different workaround.
> Using Geoff's one liner:
OK, I'll use this method.
> Also William can you check what Test::More does to deal with this problem?
> Eventually we may drop t_cmp completely and move into Test::More, whose API
> is much reacher and you better use it from the very beginning instead of
> Apache::TestUtil, if you can afford requiring Test::More.
All tests in the following script pass:
-
use Test::More tests => 2;
# Test scripts for Stas
is (
undef,
&get_undef,
"Retrieve undef from subroutine"
);
my $rv = &get_undef;
is (
undef,
$rv,
"Retrieve undef from subroutine - use variable for
comparison"
);
sub get_undef {
return;
}
-
I like that idea of adopting all of T::M. However, does T::M have a
comparable function to t_cmp that gives the expected and received
values? I *really* like the verbose output that t_cmp gives!
William
--
Knowmad Services Inc.
http://www.knowmad.com
t_cmp oddities
Hi Stas,
I've encountered an anomaly in t_cmp which seems to run against the
documented behavior. The easiest way to describe it is with an example.
In my response handler, I have the following two tests:
ok t_cmp (
undef,
&get_undef,
"Retrieve undef from subroutine"
);
my $rv = &get_undef;
ok t_cmp (
undef,
$rv,
"Retrieve undef from subroutine - use variable for comparison"
);
sub get_undef {
return;
}
Here's the output:
# expected: undef
# received: Retrieve undef from subroutine
not ok 1
# testing : Retrieve undef from subroutine - use variable for comparison
# expected: undef
# received: undef
ok 2
As you can see, the first version tries to compare the description
instead of the undef value returned from the function. Do you see
similar behavior or have I hit another problem with my environment?
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Using A::T on Windows
On Tue, Mar 16, 2004 at 10:48:53AM -0800, Stas Bekman wrote: > The only possible caveat is the the author may have mod_perl installed and > will use the wrong subclass, for his test suite and it will work just fine. > When the user w/o mp will try to run it, it'll fail. But the error message > should give the user enough info to know how to proceed. Yes, that was one of the issues that I ran across when porting my app from Linux to Windows. The error message would have been sufficient to understand the root of the problem. I certainly hope that I can buy you a one day! mod_perl has been one of the most complicated pieces of software that I've ever attempted to use. If it's this tough to understand as a user, I can only imagine the troubles that the developers have. Best regards, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Tue, Mar 16, 2004 at 10:02:31AM -0800, Stas Bekman wrote: > I think all is needed is a good clear documentation. And > Apache::TestRunPerl will now tell you if you try to use it w/o having > mod_perl. I would think that those two steps should be sufficient. -Wm -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Tue, Mar 16, 2004 at 10:03:42AM -0800, Stas Bekman wrote: > Yes, it's in TestRunPerl.pm too. You don't need to compile anything to get > the latest Apache-Test. You can always get it by checking out just it: Yes, I see it. Nice job. > cvs co modperl-2.0/Apache-Test Ta! -Wm -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Mon, Mar 15, 2004 at 06:25:27PM -0800, Stas Bekman wrote: > No, that's not fine. I've misread the code. Apache::TestRunPerl requires > mod_perl. I'm updating the docs. You need to use Apache::TestRun if you > don't want to run mod_perl. Excellent. Using TestRun simply skips the response tests. Very smart. > Admittedly it'd be better to call it Apache::TestRunModPerl, but the > assumption that Perl == mod_perl (of course mod_cgi could be just as well). > May be we could have changed it but we don't want to break test suites of > people who use that name. I'm guessing that not many folks who are using A::T are subclassing TestRun directly. Perhaps there could be a TestRunCGI module to help differentiate which module to subclass. I'm not sure that would have helped me much though since I would have ignorantly tried to use the same TEST.PL script in both locations (on a mod_perl enabled and non-mod_perl enabled server), not realizing everything that's going on behind the scenes. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Sticky preferences in Windows
On Mon, Mar 15, 2004 at 06:35:11PM -0800, Stas Bekman wrote: > because it could find itself. Try to move things with the current A-T cvs, > it should work fine (i.e. 'make clean' should delete > t/conf/apache_test_config.pm > after the project was moved), if not than more work is needed, in which > case please provide the steps to reproduce the problem. Can you tell me the module which was modified? I cannot compile under Windows. > Nothing will be overriden unless you tell it to do so. Which you get with > -save: > > perl Makefile.PL -httpd c:\apache2\bin\apache.exe -save That's good to know. > I wonder whether it'd be a good idea to invalidate invalid bits of the > saved config, e.g. if apxs is saved but can't be found on the filesystem? > So if someone install apache in one location, run A-T which saves that > location, and then nukes apache and reinstalls it into a different location > it'll drop the previously saved config since the path to apxs and/or httpd > will be invalid. This would seem to be helpful though I'm not sure it's a top priority. The frustrating thing for me was that the following command was not resetting the apache_test_config.pm settings (little did I realize at the time though that this was where the old path was being cached): `perl Makefile.pl -httpd /path/to/httpd` Not being able to clean up the environment via a `make clean` was perhaps the reason that apache_test_config.pm was not able to be rebuilt. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Mon, Mar 15, 2004 at 07:12:02PM -0800, Stas Bekman wrote: > Please try the current cvs, it should die on you much earlier if you use > the wrong Apache::TestRun subclass, with a useful error message as you have > suggested. Well, I can't compile anything under Windows, so I cannot rebuild mod_perl2 from CVS. However, I downloaded the latest version of TestConfigPerl.pm. I don't see the error message in there so am guessing its in another module. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Errors testing under Win32
On Mon, Mar 15, 2004 at 03:37:26PM -0800, Stas Bekman wrote: > >Actually, there is no 'PerlModule Apache::Response' directive in my > >normal setup and I'm not loading an external startup.pl file. > > Yes, but it could have been loaded indirectly by some module, e.g. CGI.pm > or Apache::compat, that you have loaded from httpd.conf. OK, that makes sense. Looks like it may be ModPerl::Registry which is drawing it into play when I run my scripts via the Apache server. > >>You should load this and any other required modules from the code that > >>uses it, not at the server startup. (you load at the server startup to > >>speed things up, not as a substitute to the loading from the handler's > >>module). So although it works to put 'PerlModule Apache::Response' into my httpd config, you're suggesting that I include it in my scripts? I can see where that would be the best solution for maximum portability. I'll make that change. > But please read: > http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded Thanks for the link. While reading it, I discovered there's a whole other part of the MP2 docs at perl.apache.org. So far, I had only found the "Starting with 2.0" and "Migrating to 2.0" sections. > http://perl.apache.org/docs/2.0/api/index.html is being slowly improved, > but it will take a long time till it will get completed unless more people > will contribute, since we have just a few hands. Is this why you don't have a link in the menu bar to "The 2.0 guide"? It would have been a long time before I found all the useful, albeit incomplete, info without your link. FWIW, I think it would be useful to include a link to the 2.0 material. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Errors testing under Win32
On Mon, Mar 15, 2004 at 01:22:20PM -0800, Stas Bekman wrote: > have you loaded Apache::Response? No, I wasn't aware that I needed to specify this module. > Probably because your startup/config setups are different. You loaded > 'Apache::Response' in your normal setup, but not in your A-t setup. Actually, there is no 'PerlModule Apache::Response' directive in my normal setup and I'm not loading an external startup.pl file. > You should load this and any other required modules from the code that > uses it, not at the server startup. (you load at the server startup to > speed things up, not as a substitute to the loading from the handler's > module). OK, I tried adding the PerlModule Apache::Response line to my extra.conf.in file and doing my tests. They ran fine minus a few OS-specific errors. Of course this result begs the question, why do these tests work for testing and production without use'ing 'Apache::Response' in Linux/mp1 (I checked both httpd.conf and startup.pl; neither refer to A::Response) as well as in production in Win32/mp2 (i.e., running apache as usual; even works in single server mode) but fail when tested via A::T? BTW, I tried to find documentation for Apache::Response on CPAN but there's no reference to it. Didn't find anything in the Eagle book or in _mod_perl Developer's Cookbook_. The description at perl.apache.org is "To be completed". Thanks again! William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Mon, Mar 15, 2004 at 01:33:25PM -0800, Stas Bekman wrote: > Neither to me. Are you sure you get the "Statement unlikely to be reached" > error from the same place? It happens long before the server has started, > and "failed to resolve handler" is an error from the run-time or a server > startup. > Again, giving us a tar to play with should be helpful. Yes, they are happening at line 636 which is the die statement in the set_ulimit_via_sh sub. I agree it's bizarre. I'll work on getting a reproducible test this evening. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Mon, Mar 15, 2004 at 01:30:51PM -0800, Stas Bekman wrote: > Have you been talking about mod_perl 1 all this time? Yep. > If not, you can only build mp2 as DSO at the moment. You don't need to > build perl with -Duseshrplib to get a DSO mod_perl build (certainly > for mp2, not 100% sure about mp1). OK, that's good to know. I had some build troubles several months back and must have come across some suggestions to use that option and found it to work. I prob. forgot a step initially which I did not forget when using the -Duseshrplib. At any rate, I've found that I don't need that option anymore which simplifies my build process. Cheers! William -- Knowmad Services Inc. http://www.knowmad.com
Re: testing apache 1.3 on windows
On Mon, Mar 15, 2004 at 09:04:32AM -0500, Rodent of Unusual Size wrote: > explodes with the attempt to treat the 1.3 apxs.pl as 2.0, complete > with the same -D APACHE2. Ken, I had a slightly different variation of sticky preferences problems over the weekend. I found preferences stored in the following two locations: \Apache\TestConfigData.pm t\conf\apache_test_config.pm Do you see the preferences set in either of these locations? I too never saw a .apache-test file in my home directory in Windows (XP). HTH, William -- Knowmad Services Inc. http://www.knowmad.com
Errors testing under Win32
I'm running into a problem when doing testing under Win32 that doesn't happen when testing in Linux or when I run my program in Win32 with Apache2 and modperl (Randy's binary). The error is as follows: [Sun Mar 14 18:02:02 2004] [error] [client 127.0.0.1] Can't locate object method "send_cgi_header" via package "Apache::RequestRec" at (eval 93) line 62. I can't find much information at all in the archives or on the web. It doesn't make sense to me why my scripts would work under Apache but not when called with Apache::Test. Any ideas? Any suggestions for tracking this down? I really don't know where to start. Thanks again, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Fri, Mar 12, 2004 at 10:35:08PM -0500, William McKee wrote: > Yeah, that's certainly a concern. I'd like to figure out my > misconfiguration issue above then will attempt your proposal to nuke all > these old installations and start fresh. Well, I'm now seeing this "Statement unlikely to be reached" error under Windows with a fresh ActivePerl 5.8.3 installation. This is starting to make me think that it has something to do with the way that I'm invoking Apache::Test. This time I'm getting the following additional message before the "unlikely to be reached" error: [error] failed to resolve handler 'Web::web' My test is t/response/Web/web.pm. I went back to be sure that I hadn't overlooked other errors on my Linux server and found the following message appearing *after* the "unlikely to be reached" error: [error] Undefined subroutine &Web::web::handler called. The handler is there and the test works fine if the die statement in TestRun.pm is commented out. Still doesn't make any sense to me but maybe this addt'l info helps. I'll see about putting together a test case for others to try. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Fri, Mar 12, 2004 at 08:06:05PM -0800, Stas Bekman wrote:
> Via wrappers, of course. In which case you should write several general
> purpose modules put them under project/lib (or some special lib under
> project/t) and then write the wrappers (.pl for mod_cgi, .pm for mod_perl)
> and put those under project/t. that should do the trick.
Sounds like a challenge. I've had enough of those this week, so I'll
stick with the tried and true and install the mod_perl binary ;->.
I did amend the TestConfigPerl.pm to give a bit more information in case
I or others make this mistake in the future.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- Apache-Test-1.09/lib/Apache/TestConfigPerl.pm 2004-03-04
12:24:30.0 -0500
+++ TestConfigPerl.pm 2004-03-13 13:25:21.0 -0500
@@ -483,7 +483,10 @@
# since server wasn't started yet, the modules in blib under
# Apache2 can't be seen. So we must load Apache2.pm, without which
# run_apache_test_config might fail to require modules
-require mod_perl;
+eval { require mod_perl; };
+if ($@) {
+ die "Unable to load mod_perl libraries. It appears that you are
using response handlers but do not have a mod_perl capable Apache.";
+}
if ($mod_perl::VERSION > 1.99) {
require Apache2;
}
Re: Sticky preferences in Windows
On Sat, Mar 13, 2004 at 11:23:05AM -0500, William McKee wrote: > Thanks for the pointer Randy. Actually, I tracked it down to > Apache::TestConfigData. Well, although the old value of httpd was declared in this package, deleting the key from the $Apache::TestConfigData::Vars hashref did not resolve my problem. Turns out that this value was getting saved into t/conf/apache_test_config.pm. I'm surprised that `make clean` didn't remove this file. I then had errors in my httpd.conf file. Turns out that I had to manually reconfigure the test environment by issuing the following command: `perl t\TEST -config` This cleaned everything up and fixed my paths. It also suggested running t/TEST -clean which I did. It seems to me that this would automatically be run whenever I go through the install process or when I issue make clean. Indeed it does. Turns out I somehow broke my build environment which was preventing make clean from completing its process. MORAL: Be sure your build directory is clean! Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Sticky preferences in Windows
On Sat, Mar 13, 2004 at 09:42:10AM -0600, Randy Kobes wrote: > I don't think being on Windows makes a difference in this > particular case - I think where it gets the info from is >C:\Perl\site\lib\Apache\BuildConfig.pm > which is generated by Apache::Build. Thanks for the pointer Randy. Actually, I tracked it down to Apache::TestConfigData. Here's the command I was running: perl Makefile.PL -httpd c:\apache2\bin\apache.exe It seems to me that this should have replaced what was in TestConfigData. Instead, that value was being used. I tried to track it down but am still in over my head with these scripts. Perhaps someone can explain why it didn't replace the saved value or provide a patch. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Sticky preferences in Windows
Hi Stas, I'm running into the sticky preferences problem now as well. I decided the quickest way to get my tests running in the Windows environment would be to install mod_perl. The install notes suggested that the path be c:\apache2 which means the default path of c:\program files\apache2 is no good. I uninstalled apache and reinstalled into c:\. No problems. However, now that I'm trying to rebuild my module to run my tests, the TestConfigParse.pm module is still finding the old path. I've searched my drive manually and with the built-in search tools as well as in the registry but cannot figure out where A::T has squirelled away this setting. Could you give me a pointer? This is WinXP if that makes any difference. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Fri, Mar 12, 2004 at 11:17:50PM -0500, William McKee wrote: > Just FYI, after moving the libperl.* out of /usr/lib and rebuilding > Apache/mp, I'm still having problems with the TestRun.pm module. I'll > try building Perl with O2 next. Rebuilt Perl and mod_perl with -O2. But I'm still getting the same "Statement unlikely to be reached" error message around line 636. I'm going to have to chalk it up to environmental problems for now and move on. Perhaps when I rebuild my Perl setup here, I can do further testing. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Fri, Mar 12, 2004 at 07:44:46PM -0800, Stas Bekman wrote: > that's when you start apache/mp, right? You need to remove that library and > then rebuild mod_perl. It should now find the library under > /usr/local/lib/perl5/.../libperl.so Yeah, sure enough I moved all the libperl.so.* out of the /usr/lib/ path and recompiled apache/mp. It worked fine. I don't know why I had it stuck in my build process that I needed to create these links. So do I really even need to compile Perl with -Duseshrplib? It seems like mod_perl requires this library (although I'm not building it as a DSO, I have DSO enabled and am using APACI). > >Yeah, that's certainly a concern. I'd like to figure out my > >misconfiguration issue above then will attempt your proposal to nuke all > >these old installations and start fresh. > > at least move them into some safe location (like some foo dir under your > home directory). Just FYI, after moving the libperl.* out of /usr/lib and rebuilding Apache/mp, I'm still having problems with the TestRun.pm module. I'll try building Perl with O2 next. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Fri, Mar 12, 2004 at 07:43:15PM -0800, Stas Bekman wrote: > It certainly can be patched not to do so. But I don't response handlers can > be useful for anything else besides mod_perl. It'd help if you'd have > explained what are you try to test. mod_cgi? Sorry, here's the background. I've developed a test web application framework on my Linux system which uses mod_perl. I'm trying to port this setup to Windows. I have written several tests, including response handlers that are working fine in Linux. These are failing to run in Windows. To my knowledge none of the modules I am using rely solely on mod_perl. In fact, I can get the system to run via a plain Apache server. Perhaps I need to edit my conf/extra.conf.in to let A::T know how to serve my perl scripts. Doh! Lightbulb finally went on. The response handlers are written as mod_perl handlers. I don't guess there is any way to run these as cgi scripts, eh? I don't have a compiler for Windows. Does anyone have a good recommendation for getting a binary mod_perl library for Windows? That's probably going to be the best route I suspect. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Fri, Mar 12, 2004 at 07:18:38PM -0800, Stas Bekman wrote: > No, that's fine. I should have looked at Apache/TestConfigPerl.pm line > 486. It runs that code if you have mod_perl tests. i.e. response module > t/response/TestFoo/Bar.pm. Does this mean that A::T cannot run response tests w/o modperl? Is this a permanent issue or can it be easily patched? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Fri, Mar 12, 2004 at 07:01:29PM -0800, Stas Bekman wrote: > Why do you have /usr/lib/libperl.* at all? It's a bad idea to have it in > the common path if you have more than one perl installed on the same system. > > Yes, you always need to rebuild mod_perl with the new version of perl. I must not be building this correctly because I get the following error message if I don't create the libperl.so and symlink it into /usr/lib/libperl.so: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory I can't find anything about this error in the docs or via Google. Would appreciate any insights you may have. > All I'm worried about is that you may have too many perls installed under > the same tree or on the same system, and when you use them they get > intermixed causing weird problems. So I'd suggest to completely nuke (after > backuping) /usr/local/lib/perl5 and any other places you may have remains > of perl including libperl.* and install a fresh perl, rebuild mod_perl and > then give it a try. Yeah, that's certainly a concern. I'd like to figure out my misconfiguration issue above then will attempt your proposal to nuke all these old installations and start fresh. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Using A::T on Windows
On Fri, Mar 12, 2004 at 05:26:05PM -0800, Stas Bekman wrote: > I suspect that you are subclassing ModPerl::TestRun instead of > Apache::TestRun. The former requires mod_perl, the latter doesn't not. > ModPerl::TestRun is a subclass of Apache::TestRun This would be in the TEST.PL file, right? Here's what mine looks like: - #!perl use strict; use warnings FATAL => 'all'; use lib qw(lib); use Apache::TestRunPerl (); Apache::TestRunPerl->new->run(@ARGV); - > I don't think this is documented anywhere, so please, as you discover > things, send patches to testing.pod, so you and others won't have to do it > again. Thanks. I'd be happy to send updates. Any other ideas for me to try? Any other Windows users who are using A::T with Apache w/o modperl? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Thu, Mar 11, 2004 at 04:25:42PM -0800, Stas Bekman wrote: > OK, please let us know once you get a clean build and if it's still failing > we will take it from there. Thanks. OK, finally got Perl 5.8.3 properly built. Unfortunately, my tests are still failing. However, this version of Perl is compiled with O3. I'd like to try your suggestion of using O2 but am not sure how all of the libraries tie together. Right now, I find that I have to build the shared lib via -Duseshrplib then create a symbolic link from /usr/lib/libperl.so back to the right version (currently /usr/local/lib/perl5/5.8.3/i686-linux/CORE/libperl.so. I do the same for libperl.a. If I build Perl with O2, will the .a and .so files have this setting? Will I need to rebuild modperl or will it begin using the .so with the new setting? As you can see, I'm rather confused about how all of these files fit together. I did read your discussion of installing mp at perl.apache.org. However, there were not enough low-level details for me to fit all of this together. Thanks for any advice, William -- Knowmad Services Inc. http://www.knowmad.com
Using A::T on Windows
Hi Folks, I'm trying to get A::T running under Windows. Besides the recent rash of troubles I've had with TestRun.pm, my tests are successfully running under Linux. Here's the error message I'm receiving when running `make test`: [ error] configure() has failed: Can't locate mod_perl.pm in @INC (@INC contains: C:\Tiger-0.01\blib\lib C:\Tiger -0.01\blib\arch lib blib\arch blib\lib c:\Tiger-0.01\lib\perl5.8.3 C:/Perl/lib C :/Perl/site/lib .) at c:\Tiger-0.01\lib\perl5.8.3/Apache/TestConfigPerl.pm line 486, line 68. Here's my environment: Windows XP ActiveState Perl 5.8.3 (build 809) Apache 2.0.48 (plain -- no modperl) It's my understanding that A::T should work w/o modperl. Is the above error a logical error? The code looks like it's testing the environment. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Thu, Mar 11, 2004 at 02:19:46PM -0800, Stas Bekman wrote: > You mean the current cvs without any patches starts just fine. It's only > when you run tests you get this problem? Here's something to chew on. I appear to have several copies of TestRun.pm installed on my system due to recompiling Perl. While trying to "fix" my system (i.e., cook the TestRun.pm file) so that I can get back to paying the bills, I came across the following discrepancy between @INC settings. The following is the error message I'm getting: Can't locate Apache/TestRun.pm in @INC (@INC contains: /home/quicktel/QT-Web/t /home/quicktel/QT-Web/blib/lib /home/quicktel/QT-Web/blib/arch /home/quicktel/QT-Web/t/response /usr/local/lib/perl5/5.8.2/i686-linux /usr/local/lib/perl5/5.8.2 /usr/local/lib/perl5/site_perl/5.8.2/i686-linux /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl /usr/share/perl5/ /home/quicktel/QT-Web/t/ /home/quicktel/QT-Web/t/lib/perl) Here's the @INC from running perl -V: Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Mar 11 2004 05:52:10 @INC: /usr/local/lib/perl5/5.8.3/i686-linux /usr/local/lib/perl5/5.8.3 /usr/local/lib/perl5/site_perl/5.8.3/i686-linux /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl/5.8.2/i686-linux /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl . The 5.8.3 branch isn't even showing up in the project where I'm working. I tried running 'make clean' and rebuilding via perl Makefile.PL but that made no difference. Also a 'make realclean' had no effect on the path. It's almost acting like the server is running a different perl binary. Turns out it is because I've been manually linking /usr/bin/perl to /usr/local/bin/perl5.8.x. Unfortunately, fixing that oversite has not appeared to make any difference in the error message meaning that the version of Perl running Apache is 5.8.2. Dang, that means I need to rebuild mod_perl. I always forget that step. OK, I was up all night last night and am stopping here for the night. I'll rebuild mod_perl tomorrow and try again. I don't suspect this will make any difference since these messages started coming up when I was running 5.8.2. It's worth a try though. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Thu, Mar 11, 2004 at 02:19:46PM -0800, Stas Bekman wrote: > You mean the current cvs without any patches starts just fine. It's only > when you run tests you get this problem? Yep that's what I'm seeing. I reinstalled A::T from CPAN just to confirm this since I've been messing with that TestRun.pm module quite a bit. Running t/TEST -start works w/o a problem. It's only when I do -run or call t/TEST (on it's own or specifying the tests). > >So, I uncommented the B::Concise line and here's the output: > > Before you uncommented B::Conside, was it failing? Yes. > It's still pretty foreign to me too ;) That's not very comforting ! Cheers! William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Thu, Mar 11, 2004 at 10:32:08AM -0800, Stas Bekman wrote: > rgs suggested to try B::Concise, which show you what the opcode tree looks > like. Try the patch below. Does it still fail as before? (all I did is just > commenting out some redundant code, which will not prevent us from running. > If it does fail the same way, uncomment the line: > > #B::Concise::compile(__PACKAGE__."::set_ulimit_via_sh")->(); > > run: > > % t/TEST -start > > and post the output. Thanks. I had troubles applying the patch (I was using `patch -u -p0 < TestRun.pm.diff`), so just manually made the changes. Not much to report as the server started up with no errors. I went back and uncommented the lines in set_ulimit_via_sh and tried starting the server. It starts up fine. I figured that my system was about to make a liar out of me but when I ran the tests, I got the error. Furthermore, if I commented ou the lines in set_ulimit_via_sh as per the patch you sent, I continue to get the error. So, I uncommented the B::Concise line and here's the output: --- Apache::TestRun::set_ulimit_via_sh: w <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq KP ->w 1<;> nextstate(Apache::TestRun -413 TestRun.pm:616) v/2 ->2 -<1> null vK/1 ->9 6 <|> and(other->7) vK/1 ->9 5 <2> helem sK/2 ->6 3 <1> rv2hv sKR/3 ->4 2<$> gv(*ENV) s ->3 4 <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->5 8 <@> return K ->9 7 <0> pushmark s ->8 9<;> nextstate(Apache::TestRun -413 TestRun.pm:619) v/2 ->a f<2> sassign vKS/2 ->g a <$> const(IV 1) s ->b e <2> helem sKRM*/2 ->f c <1> rv2hv sKR/3 ->d b <$> gv(*ENV) s ->c d <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->e g<;> nextstate(Apache::TestRun -413 TestRun.pm:633) v/2 ->h -<1> ex-stringify sK/17 ->k - <0> ex-pushmark s ->h j <2> concat[$original_command:FAKE] sK/TARGMY,2 ->k h <$> const(PV "ulimit -c unlimited; ") s ->i i <0> padsv[$original_command:FAKE] s ->j k<;> nextstate(Apache::TestRun -413 TestRun.pm:635) v/2 ->l n<@> exec[t4] vK ->o l <0> pushmark s ->m m <0> padsv[$original_command:FAKE] l ->n o<;> nextstate(Apache::TestRun -413 TestRun.pm:636) v/2 ->p v<@> die[t8] sK/1 ->w p <0> pushmark s ->q - <1> ex-stringify sK/1 ->v - <0> ex-pushmark s ->q u <2> concat[t6] sKS/2 ->v s <2> concat[t5] sK/2 ->t q<$> const(PV "exec ") s ->r r<0> padsv[$original_command:FAKE] s ->s t <$> const(PV " has failed") s ->u Apache::TestRun::set_ulimit_via_sh: w <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq KP ->w 1<;> nextstate(Apache::TestRun -413 TestRun.pm:616) v/2 ->2 -<1> null vK/1 ->9 6 <|> and(other->7) vK/1 ->9 5 <2> helem sK/2 ->6 3 <1> rv2hv sKR/3 ->4 2<$> gv(*ENV) s ->3 4 <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->5 8 <@> return K ->9 7 <0> pushmark s ->8 9<;> nextstate(Apache::TestRun -413 TestRun.pm:619) v/2 ->a f<2> sassign vKS/2 ->g a <$> const(IV 1) s ->b e <2> helem sKRM*/2 ->f c <1> rv2hv sKR/3 ->d b <$> gv(*ENV) s ->c d <$> const(PVIV "APACHE_TEST_ULIMIT_SET") s/BARE ->e g<;> nextstate(Apache::TestRun -413 TestRun.pm:633) v/2 ->h -<1> ex-stringify sK/17 ->k - <0> ex-pushmark s ->h j <2> concat[$original_command:FAKE] sK/TARGMY,2 ->k h <$> const(PV "ulimit -c unlimited; ") s ->i i <0> padsv[$original_command:FAKE] s ->j k<;> nextstate(Apache::TestRun -413 TestRun.pm:635) v/2 ->l n<@> exec[t4] vK ->o l <0> pushmark s ->m m <0> padsv[$original_command:FAKE] l ->n o<;> nextstate(Apache::TestRun -413 TestRun.pm:636) v/2 ->p v<@> die[t8] sK/1 ->w p <0> pushmark s ->q - <1> ex-stringify sK/1 ->v - <0> ex-pushmark s ->q u <2> concat[t6] sKS/2 ->v s <2> concat[t5] sK/2 ->t q<$> const(PV "exec ") s ->r r<0> padsv[$original_command:FAKE] s ->s t <$> const(PV " has failed") s ->u --- I hope this helps someone understand what's happening on my end. I'm afraid it's pretty foreign to me since I have not studied the Perl internals. Let me know if I can provide any further testing. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Thu, Mar 11, 2004 at 10:01:17AM -0800, Stas Bekman wrote: > Are you sure it was actually compiled with -02? Did you check 'perl -V'? Yep. Here's my latest perl -V: Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=linux, osvers=2.4.23, archname=i686-linux uname='linux vulcan 2.4.23 #1 wed dec 3 22:52:28 est 2003 i686 gnulinux ' config_args='-de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Mar 11 2004 05:52:10 @INC: /usr/local/lib/perl5/5.8.3/i686-linux /usr/local/lib/perl5/5.8.3 /usr/local/lib/perl5/site_perl/5.8.3/i686-linux /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl/5.8.2/i686-linux /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl . --- > No, that's not what I was suggesting. I suggested that you take the failing > A-T as is, and start cutting chunks of the code leading to failure and > retrying, untill you get a minimal case. This is much better than starting > from the other side. Using that approach you have a constant failure, and > you know that removing some code doesn't affect it. I follow you. Will give it a go. Thanks for pushing me to find the root of the problem. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Wed, Mar 10, 2004 at 11:46:02PM -0800, Stas Bekman wrote: > >optimize='-O3', > > that could be your problem. Try rebuilding with -02 instead. Hi Stas, Well, I tried recompiling 5.8.2 with optimize=02. No go. I tried to compile 5.8.3 (with O3) - no good. I tried to compile 5.8.3 (with O2) - no good. I'm just going to comment it out for now. At least I'm up to 5.8.3 now ;). Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Wed, Mar 10, 2004 at 10:41:15PM -0800, Stas Bekman wrote:
> % perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
Platform:
osname=linux, osvers=2.4.23, archname=i686-linux
uname='linux vulcan 2.4.23 #1 wed dec 3 22:52:28 est 2003 i686 gnulinux '
config_args='-Duseshrplib -Dotherlibdirs=/usr/share/perl5/ -de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/local/lib/perl5/5.8.2/i686-linux/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Dec 16 2003 17:36:57
@INC:
/usr/local/lib/perl5/5.8.2/i686-linux
/usr/local/lib/perl5/5.8.2
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux
/usr/local/lib/perl5/site_perl/5.8.2
/usr/local/lib/perl5/site_perl
/usr/share/perl5/
.
> Since, I can't reproduce it, I'm not sure what is abnormal about your perl,
> I'd suggest to start truncating the code that fails, till you get to the
> smallest possible case which you will be able to reproduce in a standalone
> script. Then we can ask p5p if there is some sort of bug, triggered in
> certain cases.
I copied the entire list of modules and the set_ulimit_via_sh function
into a test script but was unable to reproduce the problem. Also tried
messing with eval{} to no avail.
I was able to find another poor soul who has experienced my pain[1].
Unfortunately there was no solution. Found several threads from back in
the mid-90's which addressed several problems before the die, warn and
carp statements were allowed to come after an exec w/o triggering the
warning message. Still not enough to help me reproduce the error when
running with TEST.
William
[1]
http://mathforum.org/epigone/mason/galdcungjom/[EMAIL PROTECTED]
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Wed, Mar 10, 2004 at 02:42:45PM -0800, Stas Bekman wrote: > That's strange. What kind of Perl build do you have? It's 5.8.2 running under Debian stable. I compiled it myself (which could attribute to the problem!). > According to the exec manpage this is perfectly correct code: I see what you mean. > Do you get this problem when running: > > % perl -lwe 'use warnings; exec "echo ok"; die "should not be reached"' No problems. I tried playing with taint and some other settings but still no problems. If it matters, the library is located in the following path: /usr/local/lib/perl5/site_perl/5.8.2/i686-linux/Apache/TestRun.pm Sorry I cannot provide more details. Let me know if you need any more info. For now, I'm guessing this is an environmental problem on my side. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Failures in TestRun.pm with A::T 1.09
On Wed, Mar 10, 2004 at 05:01:34PM -0500, William McKee wrote: > This caused the tests to fail. I tried reinstalling Apache::Test 1.07 > and 1.08 but neither made any difference. I don't know why this started > showing up in 1.09, but it seems like it should be removed. I've > attached a diff that comments out these lines. Oops, please run a reverse diff if you plan on applying that patch. I'm still a newbie with diff ;). -Wm -- Knowmad Services Inc. http://www.knowmad.com
Failures in TestRun.pm with A::T 1.09
Hi Stas,
I recently upgraded my workstation for A::T 1.07 to 1.09. Immediately
upon doing so, I started to receive test failures. It turns out that
these failures were due to lines 613 and 1573 of Apache::TestRun. The
error was actually a warning as follows:
Statement unlikely to be reached at
/usr/local/lib/perl5/site_perl/5.8.2/i686-linux/Apache/TestRun.pm line
613.
However, following the examples I've seen for TEST.PL, I had the
following line in my TEST script:
use warnings FATAL => 'all';
This caused the tests to fail. I tried reinstalling Apache::Test 1.07
and 1.08 but neither made any difference. I don't know why this started
showing up in 1.09, but it seems like it should be removed. I've
attached a diff that comments out these lines.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- TestRun.pm Wed Mar 10 16:40:18 2004
+++ /tmp/TestRun.pm Wed Mar 10 16:43:00 2004
@@ -633,7 +633,7 @@
$original_command = "ulimit -c unlimited; $original_command";
warning "setting ulimit to allow core files\n$original_command";
exec $original_command;
- #die "exec $original_command has failed"; # shouldn't be reached
+die "exec $original_command has failed"; # shouldn't be reached
}
sub set_ulimit {
@@ -1570,7 +1570,7 @@
chdir $orig_cwd;
warning "rerunning '$original_command' with new config opts";
exec $original_command;
- #die "exec $original_command has failed"; # shouldn't be reached
+die "exec $original_command has failed"; # shouldn't be reached
}
sub _custom_config_prompt_path {
MaxClients error
Hi Stas et al, I'm receiving the following error message in the error.log output during my tests: [error] server reached MaxClients setting, consider raising the MaxClients setting So, I added the line 'MaxClients 5' to my extra.conf.in and reconfigured the server. I'm still getting the error. I checked that extra.conf was properly rebuilt and checked httpd.conf to make sure that extra.conf was being included after the other calls that set MaxClients to 1. It appears to me that is the case. Can someone tell me what I'm overlooking or what setting I should be modifying to stop receiving this error in my logs? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: A::T and paths
On Wed, Mar 03, 2004 at 11:49:54AM -0800, Stas Bekman wrote: > Sounds like it's unrelated to A-T, where do you load those from? Server > side or the client side? Is it the same name? If the server side and the > same name then you hit the famous problem: Yep, it was the famous problem; Scenario 3 to be precise! Thanks for the quick response. William -- Knowmad Services Inc. http://www.knowmad.com
A::T and paths
Hi Stas,
The new version of A::T is giving me some odd behavior in regards to
paths. Hopefully you can clear it up for me.
I have 3 response tests which import data from an external file via a
require statement like so:
require 'data/userdata.pl';
When run independently, each of these scripts work fine. However, if I
try to run all 3 simultaneously, the first one works and gets the data
then the following two fail to load. I've added code to output the cwd
and in all cases it is returning '/'. If I add t/ to the require
statement, I get errors. I'm not sure how to tell A::T to look into the
data directory in the t/ directory and didn't see any docs about how
A::T is handling paths with the recent updates.
I'm using the following line to check that the data was properly read
from the file:
plan $r, tests => 9, have { "Unable to load \$userdata." => defined
$userdata && ref $userdata eq 'HASH' };
I've tried switching the order these files run and I get the same
results. One weird thing I'm seeing is that the 3rd response test is
outputting a concatenated list of the have() tests as shown below:
admin/load_mail...skipped
all skipped: Unable to load $userdata., Unable to load $userdata.
When I switched the order of the tests, this concatenation did not
happen (this load_mail test was still skipped but with only a single
error message).
I suspect that I'm doing something wrong or unexpected. If necessary, I
can try to replicate this behavior in a test script.
Thanks again,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Exiting a test script if a test fails
On Fri, Feb 27, 2004 at 11:16:54AM -0800, Stas Bekman wrote: > What happens is that the client needs to read the output from the server > and then flush it out to Test::Harness. But if you server side dies it > won't send to the client the magic 'Bail out!' string. So what you could do > is instead of die'ing, use warn, to log things into error_log and then send > 'Bail out' as a response and return as if the handler was successful. OK, that solution worked. However, I'm beginning to prefer the skip method in this particular case since the output is seen by the user running the script without having any addt'l effort. > I suppose most people don't use the the bailout feature, therefore it's > still remaining a simple print and has no wrapper to do the job. So I was > suggesting for us to provide that wrapper and then hoping that Test.pm (not > Test::Harness as I've incorrectly suggested earlier) to adopt that wrapper > for everybody to use. Gotcha. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Exiting a test script if a test fails
On Thu, Feb 26, 2004 at 04:05:02PM -0800, Stas Bekman wrote: > it works perfectly fine for me. You need to do that call in the *client*. Doh! My poor brain is still having trouble with this distinction . The trouble is that the script I need to bail out of is a response test (server side). I guess I'll stick with either the die or the skip, both of which work fine. > I say we come up with Apache::Test::foo and then make Test::Harness adopt > it. OK, sounds fine to me (though I'm not sure what you mean by it). Let me know if you need me to help with anything (like testing). Thanks! William -- Knowmad Services Inc. http://www.knowmad.com
Re: Exiting a test script if a test fails
On Thu, Feb 26, 2004 at 01:17:08PM -0800, Stas Bekman wrote:
> >I tried to use it when I was messing with the pre- and post-test foo a
> >while
> >back, but couldn't get it to work. it might have had something to do with
> >the massive other changes I was trying to implement at the time, though...
>
> William will let us know.
It's not working. I placed the following lines before my die statement:
undef $userdata;
print STDOUT "Bail out! Unable to continue due to missing \$userdata"
unless defined $userdata && ref $userdata eq 'HASH';
The die statement gets called.
> >if we can get it to work, I'd be in favor of an Apache::Test::bail()
> >function (or whatever you want to call it).
>
> It's an ambiguous name since it doesn't tell you that it'll bail out from
> the whole test suite and one may think that it'll abort only the current
> test. How about:
>
> Apache::Test::abort_all_tests()
>
> or a similar, more explicit name? Suggestions are welcome of course.
The name doesn't matter to me as long as the functionality is present
(which may be outside the realm of possibility at the moment). Just for
another idea, I started looking for this ability in the Helper
Functions. A function like t_abort_all_tests("Reason goes here") would
make sense to me.
For the time being, I'll stick with either the die or the skip. Thanks
for you reponses.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Exiting a test script if a test fails
Hi all, I am looking for a graceful way to exit a test should one of my subtests fail. I don't think that I want to skip the test; I'd prefer to report an error and discontinue processing so that I don't try to add/delete bogus data into my database. However, I'm open to persusasion . I checked the docs at perl.apache.org but didn't find any helper routines or examples that fit my needs. The only thing I can image doing is adding a die statement after my test: die "Unable to read \$userdata." unless defined $userdata && ref $userdata eq 'HASH'; Any other thoughts? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: [ANNOUNCE] Apache::Test 1.08 RC1
Stas, Ignore that previous failure message. I tried to install the package on the wrong system (one without Apache installed). Once I corrected that error, everything worked fine. I was even prompted for the location of my httpd binary because it is not in the path. Test output: server localhost:8529 started t/ping...ok t/requestok All tests successful. Files=2, Tests=12, 2 wallclock secs ( 1.65 cusr + 0.20 csys = 1.85 CPU) server localhost:8529 shutdown Nice work! William -- Knowmad Services Inc. http://www.knowmad.com
Re: [ANNOUNCE] Apache::Test 1.08 RC1
On Mon, Feb 23, 2004 at 04:53:48PM -0800, Stas Bekman wrote: > We would like to release Apache::Test 1.08. It includes multiple changes > and improvements, therefore we need your help to test it and report any > problems you may have noticed. I did not see an INSTALL file so did the usual `perl Makefile.PL`. This command gave the following output: Useless use of a constant in void context at lib/Apache/TestRun.pm line 1196. Compilation failed in require at lib/Apache/TestConfig.pm line 36. BEGIN failed--compilation aborted at lib/Apache/TestConfig.pm line 36. Compilation failed in require at lib/Apache/TestMM.pm line 7. BEGIN failed--compilation aborted at lib/Apache/TestMM.pm line 7. Compilation failed in require at Makefile.PL line 16. BEGIN failed--compilation aborted at Makefile.PL line 16. Platform: Debian Sarge (testing) Perl: 5.8.2 Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Trace level defaults to 'debug'
On Wed, Jan 21, 2004 at 01:51:05PM -0800, Stas Bekman wrote: > >>LogLeveldebug > > > >That's the one I needed to set. > > You can override it later in your extra conf files. But it's a good idea to > keep it at the debug level. I was able to override but will follow your advice. The info about where to set it (extra.conf.in) and your suggestion to use LogLevel debug should probably be added to the patch I submitted. > >That makes sense now. I'm still getting the client and server stuff > >mixed up :). > > You don't. Apache::TestTrace works on the client and the server sides. It's > the tracing of Apache-Test, which is unrelated to logging of Apache. As I've recently found out. Thanks for fixing up my documentation patch. > It takes some time to learn to appreciate Apache::TestTrace. Actually, I've recently started using Log::Log4perl and find Apache::TestTrace to be a similar tool. Now that I know how to use it, I will be able to put its power to work for me. Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Trace level defaults to 'debug'
On Wed, Jan 21, 2004 at 04:31:50PM -0500, William McKee wrote: > > Please suggest a clarification to the docs now that you know all the > > answers to this issue, William ;) > > Attached :). Please ignore the previous diff. I've revised the changes to include how to output messages. William -- Knowmad Services Inc. http://www.knowmad.com --- testing.pod.orig2004-01-21 16:21:48.0 -0500 +++ testing.pod.wlm 2004-01-21 16:44:04.0 -0500 @@ -310,6 +310,16 @@ % t/TEST -trace=warning ... +To output messages in your tests use the following: + + use Apache::TestTrace; + info "doing foo"; # will be logged + debug "doing bar"; # won't be logged unless trace level is increased + +These messages are printed to STDOUT during testing. See Apache::TestTrace for +more information. To control the messages printed to the server error_log, set +the Apache directive LogLevel. See the Apache documentation at httpd.apache.org +for more details. =head2 Stress Testing
Re: Trace level defaults to 'debug'
On Wed, Jan 21, 2004 at 12:35:07PM -0800, Stas Bekman wrote: > William McKee wrote: > >The testing documentation at perl.apache.org says that the current trace > >level defaults to info. However, my system is outputting debug messages > >to the t/logs/error_log file. Is this the correct behavior in which case > >the docs are wrong? Or have I somehow configured my system to default to > >debug mode? > > What are the 'debug' messages you are talking about? The [debug] messages in the t/logs/error_log. In particular the ones that look like the following: [Wed Jan 21 15:58:25 2004] [debug] mod_cvs.c(217): CVSCheck is off here: /index.html > The Apache LogLevel is set to 'debug': > > % grep Level t/conf/httpd.conf > LogLeveldebug That's the one I needed to set. > The Apache-Test tracing mechanism is set to 'info'. so: > > use Apache::TestTrace; > info "doing foo"; # will be logged > debug "doing bar"; # won't be logged That makes sense now. I'm still getting the client and server stuff mixed up :). > Refer to the Apache::TestTrace manpage for more information. Thanks. > Please suggest a clarification to the docs now that you know all the > answers to this issue, William ;) Attached :). Thanks, William -- Knowmad Services Inc. http://www.knowmad.com --- testing.pod.orig2004-01-21 16:21:48.0 -0500 +++ testing.pod.wlm 2004-01-21 16:31:09.0 -0500 @@ -310,6 +310,10 @@ % t/TEST -trace=warning ... +These messages are printed to STDOUT during testing. See Apache::TestTrace for +more information. To control the messages printed to the server error_log, set +the Apache directive LogLevel. See the Apache documentation at httpd.apache.org +for more details. =head2 Stress Testing
Trace level defaults to 'debug'
The testing documentation at perl.apache.org says that the current trace level defaults to info. However, my system is outputting debug messages to the t/logs/error_log file. Is this the correct behavior in which case the docs are wrong? Or have I somehow configured my system to default to debug mode? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Response Handlers
Hi Stas, Geoff, Nick, et al, A quick question for you folks regarding response handlers. Now that I'm understanding how to use these tests, I'm finding that I can replace my tests that used the Apache::FakeRequest module for doing testing of my server-side code. I've also found that A::T will run these response handlers with or without a corresponding request test in t/apache/. Is this typical usage? Am I overlooking any potential gotchas in not building the request tests? Thanks again, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Mon, Jan 19, 2004 at 09:25:35AM +1300, Nick Phillips wrote: > It seems you are going through pretty much what I did a month or two > ago. I'm glad to hear it's not just me! > And eventually Stas said something that triggered that in me, too. But > I do think that a better tutorial document is needed; I just don't > have the time to write one right now. I think Geoff's article fits the bill. Of course, I didn't come to it until I had gone over Stas' documentation many, many times so I didn't exactly have fresh eyes. Still, I think it's a better starting place until we come up with an alternative. > I think the "eureka moment" for me was when Stas pointed out that you > manage the server side of the testing from handlers. The TEST program > takes your response module and uses it as a handler for the request > in question. A whole series of URLs are set up, one for each response > part, with names generated from the filenames of the response modules > you've written. The request parts of the tests can then test any of > the response modules by requesting the appropriate URL. This concept took a long time for me to understand (as you've noticed if you've been following my postings). Are you using the test module in this way or more like Geoff described? > The other confusing bit was trying to get a handle on which bit is > actually controlling the test; which bit should actually output the > test plan and the "ok" and "not ok" stuff. It's the request script, > but in many cases it is convenient for the response module to output > it into the response page, and for the request script to just output > that verbatim (particularly when you are unit testing, as you said, > subroutines used on the server side). So let me see if I follow you. The request script is the client and should output the test results. The response handler is handling the server-side requests. It can send information back to the client to output. It looked, though, like Geoff was using examples such as plan $r, tests=>9 in the response handler examples he was writing to me about. Was this incorrect usage or can you do testing in the response handler which you pass back to the request handler to output? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Response Handlers (was Re: Perl test framework, TestConfig, and debugging A::T)
On Sun, Jan 18, 2004 at 10:57:25AM -0500, Geoffrey Young wrote: > it really depends on what you're trying to accomplish. Apache-Test is for > what is generally called 'unit tests' or 'functional tests' - given known > input, make sure your code gives you the correct output. Now that you mention it, I had thought Apache-Test would be performing system tests since it utilizes a server similar to a production environment in order to do the testing. Obviously, I'm a newbie to testing and have lots to learn! I would appreciate some recommendations for books that explain the big picture view of testing. Have any titles on your bookshelf that you'd suggest for someone like myself? I don't know of any books that discuss testing specifically from a Perl perspective. Do you? Thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Sun, Jan 18, 2004 at 12:38:15AM -0800, Stas Bekman wrote: > >William, the cvs version of Apache-Test now has this bug solved. So if > >you want to use that APACHE solution try it. Though the suggested above > >solution is more efficient, as it won't reconfigure the test suite on > >every t/TEST run. Thanks. I have switched my habits as you suggested and am glad to be taking advantage of the more efficient route. I stopped using the solution of passing the httpd path into the Makefile.PL command because it stopped working for me. I suspect that I forgot to include the Apache::TestMM::filter_args() module :(. I'll second the motion that Geoff's article and skeleton frameworks should be mentioned at the top of the perl.apache.org testing document (not just listed in the References). His article is better laid out for newcomers like myself to get into this framework without having to understand all of the ins and outs that have been documented on the "Running & Developing..." page. That page is an awesome resource once someone has a basic environment working and is ready to do more advanced testing. > Though I've also changed the env variables in the cvs version: No problems. I'd prefer to reconfigure my systems to maintain consistency across the testing environment. Cheers! William -- Knowmad Services Inc. http://www.knowmad.com
Re: Response Handlers (was Re: Perl test framework, TestConfig, and debugging A::T)
On Sat, Jan 17, 2004 at 02:35:17PM -0500, Geoffrey Young wrote:
> cool. actually, I've been meaning for a while to create a :testmore import
> target that exports everything but ok() and plan() (the two that collide
> with Test::More).
That'd be very useful!
> well, it's important if you're writing an API, not merely testing CGI
> scripts or the like. for instance, suppose you have a class that subclasses
> mod_perl. if you plan'd and ok'd things from a PerlHandler then you could
> do things like
>
> isa_ok($r, 'My::Class');
>
> which you can't really do otherwise.
OK, let me see if I'm understanding. The response handler acts as a kind
of subclass that sits between modules in the project's lib/ directory
and requests. It's like a back-door into the code that is running on the
server which allows you to make your tests even more complete.
If this is correct, it's a very subtle distinction. The request test is
essentially testing the response. However, it doesn't have direct access
to the $r object that got created in response to the request--it just
gets the final data being sent back. In this sense, it seems like the
response test is like an Apache filter. If I'm grokking this correctly,
this seems like an amazingly powerful tool which would be useful to
testing an API but not as necessary for testing a web application unless
you're getting some hard-to-track bugs happening.
In Stas' example at perl.apache.org, he uses the url
'/TestApache__cool' in the request test, cool.t. I saw the paragraph at
the end of the section about developing response and request parts of a
test which described the directory layout. However, I didn't see a
discussion of how the url is created. I'm guessing that A::T takes all
the directories and files in t/response and creates Locations which
the test apache server can handle. Would the file
t/response/Mod/hot.pm create a url of '/Mod__hot'?
> I've always used environment variables. for instance, when I was testing a
> SOAP client API, I defaulted my SOAP server to localhost, but used
> %ENV{SOAP_SERVER} (or somesuch) if available. this let me run the same
> tests against both my local extra.conf.in and the production box I was
> setting up.
Coming from a DOS/Win* background (I've been using a Linux workstation
for about a year now), I'm not as familiar with the wide range of uses
for environment variables. It's good to know that others are using them
in this way. I'll continue to forge ahead.
> HTH
++
Regards,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Response Handlers (was Re: Perl test framework, TestConfig, and debugging A::T)
On Sat, Jan 17, 2004 at 09:59:03AM -0500, Geoffrey Young wrote:
> > There's one last piece that I'm still unclear on which your article did
> > not mention--reponse handlers. Is this where the two paths diverge? I'm
> > not sure that I see much difference between the way you do it and the
> > highly magical stuff.
>
> well, that's the next step. instead of calling plan() from within the test
> script, you can call
>
> plan $r, tests => 5;
>
> from within a handler() subroutine in a PerlHandler. but again, you don't
> need to use the magical parts of Apache-Test to autogenerated all the foo.
> that is, you can still write your own foo.t and extra.conf.in or whatever
> else you need.
I see why you call this code magical. It's definitely a step beyond my
understanding and probably beyond my needs for now.
> if you understand that no matter what wrapper you use - Apache-Test,
> Test::More, etc - in the end they are all just feeding "1..5" and "ok" to
> Test::Harness, then it all kinda makes sense - of course you can plan() and
> ok() from either a PerlHandler or *.t, so long as the proper sequence of
> data is printed to STDOUT.
OK, I'm beginning to see now. I was able to take my revised skeleton and
replace Apache::Test with Test::More. I had to modify the plan line to
remove the have_lwp() as that must be part of the Apache::Test module.
After that, everything worked!
Then I discovered that I can use both Apache::Test and Test::More
together with the following calls:
use Apache::Test qw('have_lwp');
use Test::More;
As you're no doubt aware, without the qw('have_lwp'), T::M overrides
subroutines like 'ok' in A::T. I was even able to add my usual test
module into the mix--HTTP::WebTest. Hey, I think things are gel'ing!
So each developer can run their own Apache process and test against it
as if it were the production server. You could even use the same binary
that is running the production server though you probably wouldn't want
to do intensive testing on a production platform. This test environment
rocks!
I still don't understand the driving need for writing tests that use
PerlHandlers but it seems best for me to leave that part of the test
framework alone until my knowledge matures.
One last question for now. Is there a way to pass additional arguments
into my scripts besides using environment variables? I use the
HTTP::WebTest module to do both local and remote testing. It'd be nice
to be able to pass an option to it to tell it to go into remote mode. I
guess doing something along the lines of the following is good:
TEST_REMOTE=1 t/TEST -run
I suppose the other option would be to write another test that would
only run if the above environment parameter is passed. Is there a better
way that folks here are using? I suspect this is rather non-standard
usage of test suites so it may be better to put my remote tests into
another location.
Many thanks!
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Fri, Jan 16, 2004 at 07:23:11PM -0800, Stas Bekman wrote: > Yes, just like the document explains. Have you read further down? It goes: Sorry, I guess I missed that part. It's a big page. > And then 4 hours later you posted another email with a list of > problems/questions. So is that the final working version or are you still > working on it? That module is in bad shape compared to the Geoff's skeleton that I'm using now. I'm just going to try porting what I can over to his format and ditch my initial efforts. Having that module a couple days ago would have spared us some of these discussions, so I do hope it gets a mention on your testing page. I really appreciate you putting up with all my fragmented questions and missing facts. Perhaps I can put together a list of things a user should provide when reporting a bug report. Of course, that's probably documented somewhere as well and I've missed it :(. Thanks! William -- Knowmad Services Inc. http://www.knowmad.com
Response Handlers (was Re: Perl test framework, TestConfig, and debugging A::T)
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote: > basically, there are two ways to approach Apache-Test: do it all yourself or > let Apache-Test add some highly magical stuff. the article I wrote takes > the first route - it assumes that you already know how to edit an httpd.conf > and are somewhat familiar with Test.pm or Test::More. the testing tutorial > shows you other parts of Apache-Test, such as letting it autogenerate tests > and configurations. > Thanks to Stas' tireless efforts to educate me as well as your articles and sample, I think that I've about got my confusion cleared up (part of which was due to a valid bug). There's one last piece that I'm still unclear on which your article did not mention--reponse handlers. Is this where the two paths diverge? I'm not sure that I see much difference between the way you do it and the highly magical stuff. > personally, I find my approach much more managable for first time users, but > YMMV. My mileage starting improving once I began to use your bug reporting skeleton. Starting with a working skeleton that implements correct practices is no doubt the best way to get started with this testing environment. Your article makes mention that this framework is easy--it is if you know how all the pieces work together (and there are several pieces). Cheers! William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Thu, Jan 15, 2004 at 05:08:39PM -0800, Stas Bekman wrote:
> strange, I saw it once and could never reproduce it again. What is the
> sequence of commands when you get it?
That is interesting. Right now, I'm playing with Geoff's
bug-reporting-skeleton-mp1 running my my Apache 1.3.29 server with
modperl 1.29 and am able to replicate this VirtualHost bug
intermittently but regularly. Let me try to explain.
I have an extra.conf.in which contains a plain VirtualHost (let's keep
the SSL out of it for now). I have a testsuite which gets the hostport
of this second server as described in your docs and gets the index page.
I run my tests and everything works.
If I try to run the tests again, the host info is not found thus
hostport does not get set and the script dies. If I go back into
extra.conf.in and make a change to the file (or simply `touch` it), my
tests will work again. However on the next attempt, and any further
attempts, the script fail when trying to get the hostport. This is
differernt from what you are reporting that the test failed first then
ran successfully ever after.
I can do the above and set the -times=100 parameter and get 100 failures
or 100 successes depending on the changes to the extra.conf.in. So what
is A::T doing internally when the extra.conf.in file changes which would
affect the virtual host config? If you would like to review my
configuration or test my module, it is available on my server[1] (at
this point the last test is failing but don't be surprised by that; the
reason is explained below; the virtual host bug will cause the tests to
die prematurely).
For completeness, I added a third server to handle SSL requests. I then
do the following requests after setting the $hostport to the secure
server:
get https://$hostport/ # get index from secure server
get / # get index from primary server?
The first test passes but the last test fails with a message that I'm
trying to speak HTTP to a HTTPS server. So it seems that the code to get
the hostport (e.g., Apache::TestRequest::module('My::SSL') )is actually
setting the test environment to continue to use that host for all
further requests. Is this correct? If so, it should be noted in the
documentation regarding Virtual Hosts.
At any rate, the tests will all pass when the first run and will
continue to fail until such time as you change or touch the
extra.conf.in. Does anyone else use VirtualHost's in their
configuration? Are you using Apache 1.3.x or Apache 2.x?
Finally, I added a test for getting a page from the primary server after
getting the hostport info using A::TR::module function. It fails. Here
is the line I'm trying to use:
Apache::TestRequest::module('');
Is there a way to set the test environment back to getting pages from
the primary server after the above has been called to get a virtualhost
configuration? It seems that this code is setting some internal
configuration values rather than just getting the values as I was
expecting.
Thanks,
William
[1] http://www.knowmad.com/~william/bug-reporting-skeleton-mp1.tar.gz
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote: > if you're feeling a bit overwhelmed but have Apache-Test installed, I'd > suggest that you start with this > > http://perl.apache.org/~geoff/bug-reporting-skeleton-mp1.tar.gz > > examine it, run it, and get a feel for how the test scripts interact with > the running server. then massage the bug.pl script and Bug.pm library > gradually to get it looking like your code. starting with such a simple > example might help everything gel together for you - Apache-Test is actually > very simple, so at this point you may be over thinking things :) Just starting to review this module but have a quick question about the layout. Why is the perl module in t/My/Bug.pm and not in lib/My/Bug.pm? In most projects, the modules to be tested are in lib/, no? Also, when running `perl Makefile.PL`, I get an error that Apache2 is not in my @INC. I cannot install this module directly via CPAN and don't see a need for it in an Apache 1.x environment so have removed it from the Makefile.PL. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Fri, Jan 16, 2004 at 02:30:45PM -0500, Geoffrey Young wrote: > no, I'm sorry - I didn't mean to sound so harsh. it just seemed to me that > this was becoming a very long thread comprised mostly of things that I knew > were answered already. apparentlly, not clearly enough, though :) Thanks for the life jacket ;->. I was starting to think I had jumped into the wrong end of the pool. There are just so many ways of coming into contact with this material that it's impossible to write documentation that works for everyone's situation. Anyhow, I'm going over your articles and references now. I'm sure that this material will begin to gel for me sooner or later. > basically, there are two ways to approach Apache-Test: do it all yourself or > let Apache-Test add some highly magical stuff. > > personally, I find my approach much more managable for first time users, but > YMMV. So far it's been one step forward, two steps back. I'll let you know how it goes with your approach. Thanks again, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Fri, Jan 16, 2004 at 02:01:15PM -0500, Geoffrey Young wrote: > you can use have_lwp() to check for LWP support. have_module() is handy too. Thanks. > > OK. FYI, I didn't see anything about this in the docs. I looked at the > > t/ dir in Apache::Test and only see request.t and ping.t. The > > extra.conf.in was basically empty. Which other test suites did you have > > in mind? > > the mod_perl test suite, as well as a number of CPAN modules. take a peek > at the Apache modules under I just grabbed the mod_perl distribution and took a look in there. I'm not grokking how these tests work and cannot run them because I don't have an Apache2 server installed. I'll try some of the modules in your directory. > > So in my case the TEST script that runs my tests is acting as the > > client? I'm not seeing how creating a response handler is going to make > > this work. Is the response handler setup in the extra.conf.in or with a > > test? > > see > > http://perl.apache.org/docs/general/testing/testing.html#Developing_Response_and_Request_Parts_of_a_Test Thanks. I overlooked that the first time and am now getting documentation blindness. It seems that the section may be missing a configuration for the extra.conf.in. How is the /TestApache__cool uri getting defined? > I've only been following this thread half-heartedly, but a number of the > questions you raise make me wonder if you've really read the available > documentation for Apache-Test. Honestly, I am trying my best. The problems I am encountering are changing perspective from a cgi to a mod_perl framework which thus entails learning lots more about the Apache server than I've ever known before. My apologies if you think these questions are inane or off-topic. As you know, network programming can be a very complex beast, esp when you don't have a very complete understanding of all the pieces involved. The documentation that you pointed me to is starting to make sense. I had thought that putting the following into my extra.conf.in would handle the dynamic responses without the need for further code: SetHandler modperl PerlResponseHandler TestApache::write I'm still perplexed at the moment as to why it does not. Hopefully further study of the documentation and the other suggestions you made will help to clear up my confusion. > I wrote a rather simple article that tries to introduce it > > http://www.perl.com/pub/a/2003/05/22/testing.html It's next on my list of reading. > which has links to other documentation at the end. the example given in the > article covers both mp1 and mp2, and has links to sample tarballs, which you > might try using as a fresh starting point for your work. That would be helpful as it seems my test package is in dire straits. Many thanks, William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Thu, Jan 15, 2004 at 09:03:54PM -0800, Stas Bekman wrote: > I didn't commit this part. I'm not sure we want to duplicate the porting > guide in this document. Instead of duplicating things, I've added a section > telling that this document uses mp2 in examples and gave a pointer to the > chapter explaining how to write config files and code that will co-exist > under both mod_perl generations. (it'll be online within 6 hours, or update > your cvs) > http://cvs.apache.org/viewcvs.cgi/modperl-docs/src/docs/general/testing/testing.pod Yeah, I was starting to think that a split may be better as well. It seems that A::T is mostly aimed at mp2 users anyhow. What's the name of the section? I'm not seeing it on the page yet. William -- Knowmad Services Inc. http://www.knowmad.com
