For example, if I put the following at the end of an almost generic httpd.conf (only host and port changed from the default install):
LoadModule perl_module modules/mod_perl.so PerlModule Not::Here
Running 'apachectl start' fails as expected because Not::Here doesn't exist.
Running 'apachectl configtest' reports 'Syntax OK'.
I think you're running into the "perl module loading is deferred" thingy that is the default behavior in mp2. if you stuck a valid <Perl> section above it you would probably see configtest fail, since an interpreter would be loaded.
basically, PerlModule no longer runs module code at the time that the PerlModule directive is parsed unless an interpreter is already resident in the configuration process. I'm not entirely certain as to the rationale for this, but I think it has something to do with startup times, overhead, interpreter pools, etc.
The main rationale I think is because of the restart, loading is twice as slow. So the more things you can postpone until after restart the faster your server will start.
It should be very easy to match the mp1 behavior. You already suggested that an empty <Perl>\n<Perl> section will trigger an early startup. And we could introduce a special directive for that, to make it less hackish. I'm not sure what's the best default behavior. This is something that we can always fix later. So let's see whether it is good or not when more people move in.
But yes, I'll document that in the porting/compat doc now. Thanks for suggestion, John.
__________________________________________________________________ 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
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
