httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: loading mod_perl first?
Date Wed, 09 Feb 2005 18:59:32 GMT

> 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. 

well, I think this is kinda a mod_perl problem, since we're only talking
about TestConfigurePerl and it's special treatment of mod_perl.  if you use
TestConfig or TestConfigPHP then the modules are just inherited from
httpd.conf (mod_perl included) in the order in which they appear there,
which is typically what the user wants.

in general, I think it is atypical that one apache module depends on another
module being loaded before it itself can load.  that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use PerlModule not
LoadModule.  embperl seems to be the exception to this.  axkit would be the
only other I could think of but I just verified that it uses PerlModule as well.

> 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...

well, I think that for the most part inheriting order from httpd.conf is
sufficient, at least for the moment, but we can always create a larger API
later when time allows.  for the moment, though, I think I'm happy to make
an exception for embperl within TestConfigPerl.  at least until somebody
complains :)


View raw message