httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
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 need 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 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 - 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 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
> functionality.  gerald, does using that file help you?

You mean is most likely not suitable 
since it's loaded after 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 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     mod_perl Guide --->

View raw message