httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: loading mod_perl first?
Date Wed, 09 Feb 2005 01:54:41 GMT
Geoffrey Young wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message