hi all...
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first, # so make sure that it's loaded before files inherited from the # global httpd.conf $self->preamble_first(IfModule => '!mod_perl.c', $cfg);
what this does is load mod_perl.so ahead of all other modules, giving it least priority. there are a few problems I see with this
- in 1.3 this is a _very_ untypical setup - mod_perl.so needs to be loaded last so that it gets first crack at each phase.
- in 2.X order doesn't matter due to the new hooking API, but it _does_ matter for overriding directives. that is, you can't load mod_perl.so first and get first crack at _directive_ parsing.
anyway, I guess what I'm saying is that 99% of the time we want mod_perl to have the highest priority, but we do the exact opposite with Apache-Test, which is probably ungood.
now, in all fairness to embperl I don't want to just yank this out without giving gerald some alternative. however, I think it's a bad idea to create a test environment that doesn't accurately represent the most common case. so, here are some possible solutions...
there are probably other modules
- historically I think this was introduced before we had extra.last.conf.in functionality. gerald, does using that file help you?
You mean extra.conf.in? extra.last.conf.in is most likely not suitable since it's loaded after modperl_startup.pl and others.
But none of custom conf files is suitable, since they are hardcoded, whereas you want to be able to dynamically find that module, so it has to be httpd.conf.
- we could provide for an extra argument to configure_libmodperl() which would place mod_perl.so first instead of the (new) default of last. this would allow folks like embperl to do something like
package My::TestConfigurePerl; our @ISA = qw(Apache::TestConfigurePerl); sub configure_libmodperl { shift->SUPER::configure_libmodperl(1) }
and have things work the way they did before. patch attached.
that's much warmer
may be we should be more flexible right away and use the same approach Apache uses, i.e. have each custom module a say for its insertion priority. So we could add mod_perl as middle module and give other modules an opportunity to load themselves before (first/very_first or after (last/very_last) mod_perl or some other module. It really shouldn't be mod_perl centric as more and more non-perl projects start to use A-T. So instead of printing the modules right away they could be assembled into an array which will be then resorted the way the user wants. e.g.:
add_foo(...., before => "mod_perl.c"); add_foo(...., after => qw[mod_perl.c mod_proxy.c]);
or have those before/after/last/first/etc encoded in the API instead...
-- __________________________________________________________________ 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
