What a fun problem to solve. Instead of banging my head against the
wall trying to get things to compile at runtime, I stopped using
ModPerl::Registry entirely and switched to defining my own pacakges with
handlers. Problem solved. Of course, how do I map these things to URLs now?
I ended up writing this:
http://search.cpan.org/~CRAKRJACK/ModPerl-PackageRegistry-0.01/
It maps /my/page.pl to MyWebsite::pages::my::page->handler(). It was
also an opportunity to play around with Apache::Test (which is really sleek,
by the way), and make my website even faster.
> If you load the modules in a startup file:
> use DBI;
> use LWP::UserAgent;
> use Time::ParseDate;
> do you get a similar error (after stopping and starting
> the server, for the changes to take effect)?
What I've done for my site is made a "yi::pages" module, which is
loaded on apache startup, and loads all of the "yi::page::" modules which
define the dynamic pages for my website... so of course, all their
dependancies get pulled in too. Loading those modules in the startup file
would probably have solved 90% of the problem, but there was still the
occasion where the registry script itself was having bizarre problems
(thining $r was a global symbol when it was instantiated as "my $r", etc...)
> Also, as a sanity check, does
> perl -c PayPal_IPN.pl
> pass?
Absolutely. That code was working fine for 3 years under mod_per
1.99. It wasn't until the move to mod_perl 2.0.2 these strangeness started
appearing. And if I get rid of ModPerl::Registry and precompile everything,
well, I've been tailing my access_log for two days and haven't seen a single
unexpected error 500 yet. :-)
- Tyler
