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, but as replied in the other message, that is not the right place to croak. I'll correct the logic to croak as early as possible to avoid confusion.
I've also found a little logic flow for the third party modules in that code. Will be fixed too.
--- Apache-Test-1.09/lib/Apache/TestConfigPerl.pm 2004-03-04
12:24:30.000000000 -0500
+++ TestConfigPerl.pm 2004-03-13 13:25:21.000000000 -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;
}
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
