RE: loading mod_perl first?
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?
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?
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?
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
Re: loading mod_perl first?
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?
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: loading mod_perl first?
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
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);
}
Re: loading mod_perl first?
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 BekmanJAm_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
