NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
use Perl Log In
geoff (2013)
geoff
reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/
see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.
reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/
see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.
Tuesday October 07, 2003
01:55 PM
configuring mod_perl with Apache-Test
of interest to people who use
if you use
the current CVS version helps to protect you from this by making sure that the default
so, now that the server starts but mod_perl isn't guaranteed to be available, here are your options:
- keep the mod_perl-specific direcitves in your
- if you don't want the server to blow up, protect your
- use
- use
oh, and for those paying attention, it's
and not
as the latter will return true for mod_perl 1.0 installations where
Apache-Test
to test their Apache:: modules...if you use
TestRunPerl to configure your tests (as you should) but the end-user of your module configures Apache-Test with a non-mod_perl-enabled Apache, the test suite will blow up before it ever starts, due to the presense of mod_perl specific directives (such as PerlRequire).the current CVS version helps to protect you from this by making sure that the default
httpd.conf does not keep your tests from running - the server will now start, leaving it up to you to decide whether your tests pass or fail.so, now that the server starts but mod_perl isn't guaranteed to be available, here are your options:
- keep the mod_perl-specific direcitves in your
extra.conf.in and your test suite keeps blowing up (same as before). if you want to let the test suite (and not your tests) decide whether make test fails due to your test environemt, this is currently your only option. personally, I consider this a bad programming practice; only the tests ought to decide whether make test is successful. I know of others that disagree, though.- if you don't want the server to blow up, protect your
extra.conf.in with <IfModule mod_perl.c>, which will allow the server to start, even if mod_perl isn't available. then- use
plan tests => $tests, have_module('mod_perl.c'); in each test where mod_perl is required, similar to the way you (should be) using have_module('mod_cgi') to skip over tests where mod_cgi is required. or- use
ok (have_module('mod_perl.c')); or some form of die if you want the tests to fail due to an improperly configured test environment.oh, and for those paying attention, it's
have_module('mod_perl.c') and not
have_module('mod_perl') as the latter will return true for mod_perl 1.0 installations where
mod_perl.pm is present, which probably isn't what you want.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Still Chokes (Score:2)
Thanks for the suggestions, Geoff. I've now made these changes for my MasonX::Interp::WithCallback module. However, when I test it against an Apache without mod_perl, it still chokes on:
I assume that's because Apache::Test 1.04 isn't fixed for this issue, yes? Apache::Test 1.05 I assume will fix it.
Cheers,
Davied
Re:Still Chokes (Score:1)
httpd -Xas mentioned in another recent journal) and ought to be in 1.05.