Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <420A6AF2.1080906@modperlcookbook.org>
Date: Wed, 09 Feb 2005 14:56:34 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040927
MIME-Version: 1.0
To: test-dev@httpd.apache.org
Subject: Re: loading mod_perl first?
References: <4208E5BB.4080502@modperlcookbook.org>
 <42096D61.8050300@stason.org> <420A5D94.2030903@modperlcookbook.org>
 <420A5FE7.1020406@chrislaco.com>
In-Reply-To: <420A5FE7.1020406@chrislaco.com>
Content-Type: multipart/mixed;
 boundary="------------040304030500050204000404"

--------------040304030500050204000404
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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

--------------040304030500050204000404
Content-Type: text/x-patch;
 name="embperl.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="embperl.diff"

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);
 
 }
 

--------------040304030500050204000404--