Re: [PATCH] Allow loading builtin dso modules

2004-12-25 Thread Chia-Liang Kao
Hi Stas,

Merry Christmas and thanks for the xmas modperl rc. :)

I just noticed that I was doing something wrong for find_and_load_module.
It checks .so rather than .c in IfModule, and this causes modules being
loaded twice if they are compiled in.

On Sun, 19 Dec 2004 23:46:59 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
 (find_and_load_module): New.
 I like the find_and_load_module wrapper as it refactors some code dups.


Re: [PATCH] Allow loading builtin dso modules

2004-12-25 Thread Stas Bekman
Chia-Liang Kao wrote:
Hi Stas,
Merry Christmas and thanks for the xmas modperl rc. :)
You too :)
I just noticed that I was doing something wrong for find_and_load_module.
It checks .so rather than .c in IfModule, and this causes modules being
loaded twice if they are compiled in.
I've noticed that too, but didn't have a chance to look at it yet. do you 
have a patch?

On Sun, 19 Dec 2004 23:46:59 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
  (find_and_load_module): New.
I like the find_and_load_module wrapper as it refactors some code dups.

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


Re: [PATCH] Allow loading builtin dso modules

2004-12-25 Thread Stas Bekman
Chia-Liang Kao wrote:
Just produced one.
On Sat, 25 Dec 2004 09:51:37 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
I've noticed that too, but didn't have a chance to look at it yet. do you
have a patch?

Patching locally against mirror source
thanks Chia-Liang Kao, committed with a tiny tweak.
--
__
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


Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Stas Bekman
Chia-Liang Kao wrote:
It seems I can never reach the list from my mail server.
May be apache.org blocks it?
Chia-Liang Kao, Please post messages inlined so it's easier to comment on 
those. Inlining this one for you:

Auto-merging (0, 1125) /Apache-Test to /remote/Apache-Test (base 
/remote/Apache-Test:1123).
Patching locally against mirror source 
http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test.
U   lib/Apache/TestConfig.pm
 Patch - level 1
Source: 1bc2e5b2-7eeb-0310-aef5-f4fb8ed75f6b:/Apache-Test:1125
Target: 
13f79535-47bb-0310-9956-ffa450edef68:/httpd/test/trunk/perl-framework/Apache-Test:122719

(http://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test)
Log:
 [EMAIL PROTECTED]:  clkao | 2004-12-20 10:24:22 +0800
 local branch
 [EMAIL PROTECTED]:  clkao | 2004-12-20 10:28:30 +0800
 Allow core modules to be loaded explicitly with find_and_load_module.
 This allows the apache from FreeBSD ports (with most modules built as
 shared) to run tests with Apache::Test, and also allows testing svk
 with a dav server.
 * Apache/TestConfig.pm:
   (find_and_load_module): New.
   (generate_types_config): Use find_and_load_module to load mod_alias.
   (httpd_config): Load mod_cgi and mod_access as they are part of the
 core tests.
=== lib/Apache/TestConfig.pm
==
--- lib/Apache/TestConfig.pm  (revision 122719)
+++ lib/Apache/TestConfig.pm  (patch - level 1)
@@ -404,6 +404,9 @@
 $self-{server}-post_config;
+$self-find_and_load_module ('mod_cgi.so');
+$self-find_and_load_module ('mod_access.so');
+
 $self;
 }
@@ -1204,6 +1207,18 @@
 };
 }
+sub find_and_load_module {
+my ($self, $name) = @_;
+my $mod_path = $self-find_apache_module($name) or return;
+my ($sym) = $name =~ m/mod_(\w+)\./;
+
+if ($mod_path  -e $mod_path) {
+$self-preamble(IfModule = !$name,
+qq{LoadModule ${sym}_module $mod_path\n});
+}
+return 1;
+}
+
 sub replace_vhost_modules {
 my $self = shift;
@@ -1257,11 +1272,7 @@
 # handle the case when mod_mime is built as a shared object
 # but wasn't included in the system-wide httpd.conf
-my $mod_mime = $self-find_apache_module('mod_mime.so');
-if ($mod_mime  -e $mod_mime) {
-$self-preamble(IfModule = '!mod_mime.c',
-qq{LoadModule mime_module $mod_mime\n});
-}
+$self-find_and_load_module ('mod_mime.so');
 unless ($self-{inherit_config}-{TypesConfig}) {
 my $types = catfile $self-{vars}-{t_conf}, 'mime.types';
@@ -1513,6 +1524,8 @@
 my $out = $self-genfile($conf_file);
+$self-find_and_load_module('mod_alias.so');
+
 $self-preamble_run($out);
 for my $name (qw(user group)) { #win32/cygwin do not support
@@ -1534,14 +1547,6 @@
 # handle the case when mod_alias is built as a shared object
 # but wasn't included in the system-wide httpd.conf
-my $mod_alias = $self-find_apache_module('mod_alias.so');
-if ($mod_alias  -e $mod_alias) {
-print $out EOF;
-IfModule !mod_alias.c
-LoadModule alias_module $mod_alias
-/IfModule
-EOF
-}
 print $out IfModule mod_alias.c\n;
 for (keys %aliases) {
 BEGIN SVK PATCH BLOCK 
Version: svk 0.26 (freebsd)
eJyNlM9v3EQUxxdEQrJAFQIU8VND40hJi7P22F7vumi1LbSVKKoQ2fQEWo3t512zXtuyZ5OuMEj2
pgiJctucuCAu9MQFBJcKDnDpqb3xR0SIKwcOPM8maZACRdqVxjPvfb7vvXnzLied8201a7WUTFKV
bPP6Vct6l3Gnv6rqmVTPwPV5lEhGFsA2BJKWBVFP0rOQDQFP02iUOOWCs6QHvFz4zgB4q6UirjHD
XRKIQ6yg2oxHYSo1Bb7LEwBJzfS2kbW18teV1GaWAp4IbDeBbT/1oxCFVZUaaIHmKrpHMYTdJIpK
ZZVSU222aemtZE4QpdAt8biDYHSgEqYkPFw/AQdjGpf5+LaAHQGEvHEAeGCJNkck7QQSaiKqdiFm
Th+E2sOJ9IioHybj+QFIVD/GqnUg5W9Goef3NuKhUH84WZuRxSmL42Dc5XCDuxBwJtQ0mhm24dk2
NZpKwzQbike9hmrXTVtTdc+u2xgF1fACr1Uqu9/Ud28/n58/XdlfqSwU06X8sd0vnysW8j9X5oup
NHmimG7Y+6/Of33xcVxV8q8q+y9s7a8u578Mns1/fWRucvfMU3+990wxXb5S3FpZ/PaTxcnv527O
Tb6AhfynTj6X//zSXP6HXSz8oCwW0+al4tYbiLyyNPlx/uViahfz+b2nlye3Xzxd7L3y6aliz5yb
3PngyWLv7VOT75Yqn31YfL6M8uhytvL9YrF3vYPaxb1q5Wa1uLtZyX97tLivh8x1ev6alI6Hw/c3
zrwmfYSrj9v68W4RtT+ojkZ1o2k2mEo1zzW1usbAYB40VMdhrqnWRc8YRjMjCbak3ma2RYgTDFhE
MkIVRZdVKlOFqIpFdYtSck5pKEqVBJHDAmInLHT6VeFr/Kdvw9KUQ98LQRDtECdKgAwjdxRASnhE
bEAoc8ElcCMOfMfnwZjs+LxPPD90uwz/5Xl35rJRJZ2+nxJWstC/D4SJNiNeEg3JZXyKFzffInGU
8JSsCcwwSvmRoD3yA05YWiVpnyXgrpchJKOQcOzSdKY761vLKhv3dYIBoFoaHUnirh/2SLo9qM7s
GXHZNkkh2YYE46uSs+Sk1reqhJC1k5Jat8g12NkQ5z0IIWEcunwcQ9p1hDcabKVwYkHK+MvPMsMu
C3yWzjh9zmP3gfs7hybYRSIlYe44kGItRR3HBOtBYpZwEnnlRokhs+sSxSm5VewbudWiGb6u2XTs
iBFnWVuhj+mnLFitZzjnYsb7OJ1w8uHHaOS7kkqzg4kgl2U5mIWShsPAdigYNpVNAFtWNFWRGXiG
7OFDboBrGl7dbq3T7N/Iup7VRLq1Ms4ax+sc1GJIAtlLcM7vRMngH8qH40doa57ZNDRD1k37QLvZ
NOqy5zHdUMAFr96QDP1/xWgdV7HK7P4GoC8suA==
 END SVK PATCH BLOCK 
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 

Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Stas Bekman
Chia-Liang Kao wrote:
 Allow core modules to be loaded explicitly with find_and_load_module.
 This allows the apache from FreeBSD ports (with most modules built as
 shared) to run tests with Apache::Test, and also allows testing svk
 with a dav server.
 * Apache/TestConfig.pm:
   (find_and_load_module): New.
   (generate_types_config): Use find_and_load_module to load mod_alias.
   (httpd_config): Load mod_cgi and mod_access as they are part of the
 core tests.
I like the find_and_load_module wrapper as it refactors some code dups.
But I don't think A-T should try to load any module someone may need in 
their test suite. It does have a bunch of mp2 specific things which should 
be wiped away and moved into the mp2 test suite.

This is your own test suite that you have the problem with, right? In 
which case I'd prefer to see a patch which subclasses Apache::TestConfig, 
so any test suite using A-T could decide which modules it wants to enforce 
loading from t/TEST. As we don't have any examples of how to subclass 
A-TC, let me know if you need help (it might be a tricky thing to do). You 
can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL.

Another possible solution is to provide a t/TEST option -load_module, 
which can be repeated several times, and will try to call your 
find_and_load_module. So you could add it into t/TEST directly as if it 
was passed from the command line.

+$self-find_and_load_module ('mod_cgi.so');
+$self-find_and_load_module ('mod_access.so');

+sub find_and_load_module {
+my ($self, $name) = @_;
+my $mod_path = $self-find_apache_module($name) or return;
+my ($sym) = $name =~ m/mod_(\w+)\./;
+
+if ($mod_path  -e $mod_path) {
+$self-preamble(IfModule = !$name,
+qq{LoadModule ${sym}_module $mod_path\n});
+}
+return 1;
+}

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


Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Stas Bekman
Chia-Liang Kao wrote:
On Sun, Dec 19, 2004 at 11:46:59PM -0500, Stas Bekman wrote:
But I don't think A-T should try to load any module someone may need in
their test suite. It does have a bunch of mp2 specific things which should
be wiped away and moved into the mp2 test suite.

Yes, originally I was trying to make the test load the module when it
plans with need_module().  But I realized later that the config file was
cached when MM/MB is invoked.  So I forced it to load the two modules
which A-T's own test wants.

This is your own test suite that you have the problem with, right? In
which case I'd prefer to see a patch which subclasses Apache::TestConfig,
so any test suite using A-T could decide which modules it wants to enforce
loading from t/TEST. As we don't have any examples of how to subclass
A-TC, let me know if you need help (it might be a tricky thing to do). You
can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL.

As said earlier, this was to make A-T's test suite actually runs the cookie
tests when mod_cgi is built as dso, and has nothing to do with my own tests.
Aha! That wasn't clear from your description. And the access module, it's 
needed for the basic test suite too?

My current tests are just using A-TC to write the config, not the whole TR
framework, so I'm forcing the load of mod_dav_svn directly.
(see: http://svn.clkao.org/svnweb/svk/checkout/trunk/t/50dav.t)
Sweet!
--
__
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


Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Chia-Liang Kao
On Sun, Dec 19, 2004 at 11:46:59PM -0500, Stas Bekman wrote:
 But I don't think A-T should try to load any module someone may need in
 their test suite. It does have a bunch of mp2 specific things which should
 be wiped away and moved into the mp2 test suite.

Yes, originally I was trying to make the test load the module when it
plans with need_module().  But I realized later that the config file was
cached when MM/MB is invoked.  So I forced it to load the two modules
which A-T's own test wants.

 This is your own test suite that you have the problem with, right? In
 which case I'd prefer to see a patch which subclasses Apache::TestConfig,
 so any test suite using A-T could decide which modules it wants to enforce
 loading from t/TEST. As we don't have any examples of how to subclass
 A-TC, let me know if you need help (it might be a tricky thing to do). You
 can see how we subclass Apache::TestRun in Apache-Test/t/TEST.PL.

As said earlier, this was to make A-T's test suite actually runs the cookie
tests when mod_cgi is built as dso, and has nothing to do with my own tests.

My current tests are just using A-TC to write the config, not the whole TR
framework, so I'm forcing the load of mod_dav_svn directly.

(see: http://svn.clkao.org/svnweb/svk/checkout/trunk/t/50dav.t)

Cheers,
CLK


Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Chia-Liang Kao
On Mon, 20 Dec 2004 00:14:08 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
  As said earlier, this was to make A-T's test suite actually runs the cookie
  tests when mod_cgi is built as dso, and has nothing to do with my own tests.
 
 Aha! That wasn't clear from your description. And the access module, it's
 needed for the basic test suite too?

Yes.  t/conf/extra.conf.in has Order allow,deny

Cheers,
CLK


Re: [PATCH] Allow loading builtin dso modules

2004-12-20 Thread Stas Bekman
Stas Bekman wrote:
Chia-Liang Kao wrote:
On Mon, 20 Dec 2004 00:14:08 -0500, Stas Bekman [EMAIL PROTECTED] wrote:
As said earlier, this was to make A-T's test suite actually runs the 
cookie
tests when mod_cgi is built as dso, and has nothing to do with my 
own tests.

Aha! That wasn't clear from your description. And the access module, 
it's
needed for the basic test suite too?

Yes.  t/conf/extra.conf.in has Order allow,deny

Yup. I'll figure out how to fix that, w/o trying to load those modules 
for every test suite using A-T. (And I'll add your wrapper too 
find_and_load_module so it'll be in 1.18)

thanks a lot, Chia-Liang Kao.
well, I've cheated and for now simply dropped the requirement for 
mod_access from the config file. As for mod_cgi, it's properly 
conditioned. So the test shouldn't fail now (to start with).

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