You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2005/02/08 17:15:55 UTC
loading mod_perl first?
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...
- historically I think this was introduced before we had
extra.last.conf.in functionality. gerald, does using that file help you?
- 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.
thoughts?
--Geoff
RE: loading mod_perl first?
Posted by Gerald Richter <ri...@ecos.de>.
Hi
>
> >
> > This solution looks good to me, but should be mod_embperl.c
> instead of
> > Embperl.c.
>
> well, I went to the embperl site and added this to my httpd.conf
>
> LoadModule embperl_module /tmp/Embperl.so
>
> and things worked out as expected
>
> [ debug] /tmp/Embperl.so is already absolute
> [ debug] /tmp/Embperl.so successfully resolved to existing
> file /tmp/Embperl.so
> [ debug] Found: embperl_module => Embperl.c
> [ debug] Skipping LoadModule of Embperl.c
>
> is this not a correct setup? or it is for apache2 and not apache 1.3?
>
Looks like you done the right thing. As said I am not at home and cannot
test at the moment, so I told you mod_embperl.c from my mind, but it looks
like I am wrong. I will check this next week when I am back and give you a
feedback.
Gerald
Re: loading mod_perl first?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> This solution looks good to me, but should be mod_embperl.c instead of
> Embperl.c.
well, I went to the embperl site and added this to my httpd.conf
LoadModule embperl_module /tmp/Embperl.so
and things worked out as expected
[ debug] /tmp/Embperl.so is already absolute
[ debug] /tmp/Embperl.so successfully resolved to existing file
/tmp/Embperl.so
[ debug] Found: embperl_module => Embperl.c
[ debug] Skipping LoadModule of Embperl.c
is this not a correct setup? or it is for apache2 and not apache 1.3?
--Geoff
RE: loading mod_perl first?
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
> > Index: TestRunPerl.pm
> > ===================================================================
> > --- TestRunPerl.pm (revision 153110)
> > +++ TestRunPerl.pm (working copy)
> > @@ -35,6 +35,9 @@
> >
> > # Apache::TestConfigPerl already configures mod_perl.so
> > Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
> > +
> > + # skip over Embperl.so - it's funky
> > + Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
> > }
> >
This solution looks good to me, but should be mod_embperl.c instead of
Embperl.c.
The reason why Embperl.so needs to loaded in the Apache config, is that it
adds Apache configuration directives to Apache, so you can write
Embperl_XXX foo
Instead of
PerlSetEnv EMBPERL_XXX foo
In Apache 1.3 this works without explicitly loading Embperl.so, just via
PerlModule, but for Apache 2 Embperl.so needs to be loaded via LoadModule,
otherwise it's to late for adding config directives. So the problem will
occur with all modules that adds configuration directives to Apache and you
are right that is not common. The only one I know is AxKit, which currently
runs only on mod_perl 1.
Gerald
P.S. I am currently on the German Perl Workshop, so I cannot test. I will
test this change when I am back.
Re: loading mod_perl first?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
+1
> Index: TestRunPerl.pm
> ===================================================================
> --- TestRunPerl.pm (revision 153110)
> +++ TestRunPerl.pm (working copy)
> @@ -35,6 +35,9 @@
>
> # Apache::TestConfigPerl already configures mod_perl.so
> Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
> +
> + # skip over Embperl.so - it's funky
> + Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
> }
>
> sub configure_modperl {
> Index: TestConfigPerl.pm
> ===================================================================
> --- TestConfigPerl.pm (revision 153110)
> +++ TestConfigPerl.pm (working copy)
> @@ -94,10 +94,7 @@
> debug $msg;
> }
>
> - # 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);
> + $self->preamble(IfModule => '!mod_perl.c', $cfg);
>
> }
>
--
__________________________________________________________________
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
Re: loading mod_perl first?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Christopher H. Laco wrote:
> Geoffrey Young wrote:
>
>> 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.
>
>
> Don't the new 2.x proxy modules have the same type of dependency?
>
> mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
> but I've never tried loading them out of order to see if they fail.
yeah, that seems to be the case. and apparently there are some things that
may require mod_dav as well.
but generally this isn't an issue, since we inherit the order, as well as
module location, from httpd.conf. of course, if mod_dav wanted to use
Apache-Test for its own development it wouldn't inherit from httpd.conf but
would create its own TestConfigDav.pm class to handle things for it.
what makes mod_perl unique in this circumstance is that we are making
exception for Embperl, which is really a third party module that we have no
control over - anybody can have a custom mod_foo that depends on mod_perl or
any other module, but that doesn't mean we need to account for it in
Apache-Test land.
anyway, I'm starting to think that the best solution is like the one I've
attached here, at least for the moment. what this means is that people with
Embperl in their httpd.conf won't have problems, while people wanting to
explicitly test Embperl will have to do what everyone else needs to do -
subclass TestConfig.pm and determine the module loading order themselves.
--Geoff
Re: loading mod_perl first?
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
> 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.
Don't the new 2.x proxy modules have the same type of dependency?
mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
but I've never tried loading them out of order to see if they fail.
-=Chris
Re: loading mod_perl first?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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 :)
--Geoff
Re: loading mod_perl first?
Posted by Stas Bekman <st...@stason.org>.
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
Re: loading mod_perl first?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> - historically I think this was introduced before we had
>>extra.last.conf.in functionality. gerald, does using that
>>file help you?
>>
>
>
> I don't use Apache::Test (unless I install a new mod_perl and run make
> test). If I remember right the reason why this was introduced, was that
> mod_perl copied the LoadModule over from httpd.conf and the tests fails
> then, when Embperl.so is loaded before mod_perl.so, because there are
> unresolved symbols.
ah, right. it's because you use LoadModule for embperl, right? writing a
module that relies on mod_perl this way is probably fairly uncommon. maybe
axkit, but I doubt many others.
but since we inherit from your httpd.conf changing the current behavior
would mean you wouldn't even be able to test mod_perl since apache wouldn't
even start? hmph.
--Geoff
RE: loading mod_perl first?
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
> 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...
>
> - historically I think this was introduced before we had
> extra.last.conf.in functionality. gerald, does using that
> file help you?
>
I don't use Apache::Test (unless I install a new mod_perl and run make
test). If I remember right the reason why this was introduced, was that
mod_perl copied the LoadModule over from httpd.conf and the tests fails
then, when Embperl.so is loaded before mod_perl.so, because there are
unresolved symbols.
I am not sure if this is still a problem.
> - 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.
>
I am not sure if I understand the whole picture, since digging in
Apache::Test was some time ago for me, but it looks like that this change
might make sense.
Gerald
> thoughts?
>
> --Geoff
>