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