Re: A::T blib vs lib
Hi,
A test against my project show's no real difference at all. I applied the
patch against Apache-Test-1.04 and I verified that my t/conf/modperl_inc.pl
contain the desired lines.
use lib '/tmp/ap_ex/blib/arch';
use lib '/tmp/ap_ex/blib/lib';
1;
my error message is the following:
...
/home/ptest/httpd/bin/httpd -X -d /tmp/ap_ex/t -f /tmp/ap_ex/t/conf/httpd.conf
-DAPACHE1 -DPERL_USEITHREADS
using Apache/1.3.28
waiting for server to start: .Syntax error on line 35 of /tmp/ap_ex/t/conf/
extra.conf:
Can't locate Apache/PageKit.pm in @INC (@INC contains: /home/ptest/lib/
perl5/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1 /home/ptest/
lib/perl5/site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/
site_perl/5.8.1 /home/ptest/lib/perl5/site_perl . /tmp/ap_ex/t/ /tmp/ap_ex/t/
lib/perl) at /tmp/ap_ex/t/conf/extra.conf line 33.
BEGIN failed--compilation aborted at /tmp/ap_ex/t/conf/extra.conf line 33.
!!!
server has died with status 255 (t/logs/error_log wasn't created, start the
server in the debug mode)
my t/conf/extra.conf.in contains
## t/conf/extra.conf.in
Location /
SetHandler perl-script
PerlSetVar PKIT_ROOT @ServerRoot@/../eg
PerlSetVar PKIT_SERVER staging
PerlHandler +Apache::PageKit
Perl
# CPAN Modules required for pagekit
use Apache::URI ();
use Apache::Cookie ();
use Apache::Request ();
use Apache::SessionX ();
use Apache::Util ();
use Compress::Zlib ();
use File::Find ();
use HTML::FillInForm ();
use HTML::Parser ();
use HTML::Template ();
use XML::LibXML ();
use Apache::PageKit;
Apache::PageKit-startup('@ServerRoot@/../eg','staging');
/Perl
/Location
Am Montag, 20. Oktober 2003 05:36 schrieb Stas Bekman:
Stas Bekman wrote:
We discussed with Boris offline that we want to change the current
behavior of A::T, where it puts lib/ as the first entry in @INC. We
agreed to have a special maintainer mode (Env var/option) which will
turn on the current behavior, and by default blib/ dirs are to be first
in @INC.
Sorry for taking that long. Please try the patch at the end of this
message.
Is everybody happy with the name of the env var APACHE_TEST_LIVE_DEV, when
when set to 1, will prepend the project/lib directory to @INC and otherwise
won't do anything special about it. e.g. in the new Apache::VMonitor dir:
% env t/TEST -conf
produces t/conf/modperl_inc.pl:
use lib '/home/stas/work/modules/Apache-VMonitor-2.0/blib/arch';
use lib '/home/stas/work/modules/Apache-VMonitor-2.0/blib/lib';
use Apache2;
1;
and:
% env APACHE_TEST_LIVE_DEV=1 t/TEST -conf
produces t/conf/modperl_inc.pl:
use lib '/home/stas/work/modules/Apache-VMonitor-2.0/blib/arch';
use lib '/home/stas/work/modules/Apache-VMonitor-2.0/blib/lib';
use Apache2;
use lib '/home/stas/work/modules/Apache-VMonitor-2.0/lib';
1;
(It was broken before anyway, since 'use Apache2' was loaded last, pushing
'lib' down.)
Index: lib/Apache/TestConfigPerl.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigPerl.p
m,v retrieving revision 1.77
diff -u -r1.77 TestConfigPerl.pm
--- lib/Apache/TestConfigPerl.pm 7 Oct 2003 17:44:58 - 1.77
+++ lib/Apache/TestConfigPerl.pm 20 Oct 2003 04:29:28 -
@@ -81,9 +81,8 @@
my $top = $self-{vars}-{top_dir};
my $inc = $self-{inc};
-my @trys = (catfile($top, 'lib'),
-catfile($top, qw(blib lib)),
-catfile($top, qw(blib arch)));
+my @trys = (catdir($top, qw(blib lib)),
+catdir($top, qw(blib arch)));
for (@trys) {
push @$inc, $_ if -d $_;
@@ -160,6 +159,14 @@
}
my $fixup = Apache::TestConfig-modperl_2_inc_fixup();
print $fh $fixup;
+
+# if Apache::Test is used to develop a project, we want the
+# project/lib directory to be first in @INC (loaded last)
+if ($ENV{APACHE_TEST_LIVE_DEV}) {
+my $dev_lib = catdir $self-{vars}-{top_dir}, lib;
+print $fh use lib '$dev_lib';\n if -d $dev_lib;
+}
+
print $fh 1;\n;
}
__
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
--
Boris
Re: A::T blib vs lib
Hi, Am Dienstag, 21. Oktober 2003 09:00 schrieb Stas Bekman: Boris Zentner wrote: Hi, A test against my project show's no real difference at all. I applied the patch against Apache-Test-1.04 and I verified that my t/conf/modperl_inc.pl contain the desired lines. use lib '/tmp/ap_ex/blib/arch'; use lib '/tmp/ap_ex/blib/lib'; 1; Perfect. You are now talking about a different issue. If you look at t/conf/httpd.conf, t/conf/extra.conf is loaded before t/conf/modperl_startup.pl (which loads t/conf/modperl_inc.pl and t/conf/modperl_inc.pl) that's why you have this problem. What you want to do is to move all the code from the Perl sections in t/conf/extra.conf.in into t/conf/modperl_extra.pl, which is loaded after t/conf/modperl_inc.pl and you will be alright. Ok, I moved the code to modperl_extra.pl.in. But no success. A look into the generated httpd.conf shows that modperl_extra.pl is loaded before modperl_startup which load modperl_extra again and modperl_inc. If I remove the perlrequire modperl_extra.pl line and run ./t/TEST, I load Apache::PageKit again from ./lib waiting for server to start: ok (waited 0 secs) server localhost:8529 started 1_dummyCan't locate Text/Iconv.pm in @INC (@INC contains: /tmp/ap_ex/ Apache-Test/lib /tmp/ap_ex/lib /tmp/ap_ex/blib/lib /tmp/ap_ex/blib/arch / home/ptest/lib/perl5/5.8.1/i686-linux-thread-multi /home/ptest/lib/ perl5/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1 /home/ptest/ lib/perl5/site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/ site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/ site_perl/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/ i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/ lib/perl5/site_perl . /home/ptest/lib/perl5/5.8.1/i686-linux-thread-multi / home/ptest/lib/perl5/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/ i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/ lib/perl5/site_perl .) at /tmp/ap_ex/lib/Apache/PageKit.pm line 21. Another point is that if I move the code out of the extra.conf this change conditional, that I have to move it out of its context. I can workaround this but others may not. here is a little example: Location /xyz SetHandler perl-script PerlSetVar PKIT_ROOT @ServerRoot@/../xyz PerlSetVar PKIT_SERVER staging PerlHandler +Apache::PageKit Perl use Apache::PageKit; Apache::PageKit-startup; /Perl /Location Location /abc SetHandler perl-script PerlSetVar PKIT_ROOT @ServerRoot@/../abc PerlSetVar PKIT_SERVER production PerlHandler +Apache::PageKit Perl use Apache::PageKit; Apache::PageKit-startup; /Perl /Location in my example above I call Apache::PageKit-startup two times but both get different PKIT_ROOT and PKIT_SERVER values from the server. This change, if I move it out of the Location directive. __ 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 -- Boris
Re: A::T blib vs lib
That was a very good hint. It allows me to keep the perl part into the apache directives as desired. But my @INC path is still wrong. hmm. ok, how about you show us a few things, like all of modperl_inc.pl, then what directories you would like included that are missing. and also show us your @INC. if the libraries are properly specified in modperl_inc.pl but not in @INC, that's one thing. if they are not in modperl_inc.pl that's another. right now, I'm unclear as to what the problem is exactly. --Geoff
RELEASE document
hi all in preparation for the upcoming 1.05 release, I'm going to create a RELEASE document in the Apache-Test directory. I've attached a preliminary version here, which is essentially copied from the one for mod_perl (with a few adjustments). if I'm missing anything or something isn't right, please speak up. if it's mostly right but easier to tweak via CVS, just let me know and I'll commit it. --Geoff Instructions for Apache-Test Release Manager 1. 'make dist' - to make sure nothing is missing from the manifest, etc. Now test this generated package (not cvs) with as many configurations as possible on as many platforms as possible. a. nuke any preinstalled Apache-Test libs and run 'make test' b. test that you can 'make install' and then run 'make test' again c. test whether we still 100% OK on systems with no LWP: % APACHE_TEST_PRETEND_NO_LWP=1 make test 2. once confident that the package is good, upload a release candidate to perl.apache.org/~username and post 24 hour-ish candidate alert to the httpd-test/modperl/dev list (may be longer to give most people a chance to catch up). no need to tag this package a. if problems are detected during stage 2, repeat stages 1 and 2. 3. when the package has been reported to be good, prepare a new package to be released a. edit ./Changes: - remove '-dev' - add release date b. make sure tag looks right (might need to rerun Makefile.PL) % make -n cvs_tag c. commit Changes % cvs ci Changes d. tag % make cvs_tag e. create the final package % make dist f. test the final package again at least once 4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz) a. upload to www.apache.org:/www/perl.apache.org/dist/ b. remove releases older by 2 subversions (keep the last one) 5. Upload the package to CPAN 6. Announce the package a. post ... to the modperl, announce lists Subject: [ANNOUNCE]: mod_perl 1.99_11 include - MD5 sig (as it comes from CPAN upload announce). - the latest Changes 7. Prepare for the next cycle a. increment version in lib/Apache/Test.pm b. edit ./Changes: - start a new item with incremented version + '-dev' =item 1.06-dev c. commit Changes % cvs ci Changes lib/Apache/Test.pm
Re: A::T blib vs lib
That leads to different version of Apache:PageKit in the lib and blib/lib directories. With the current version of Apache::Test the version in lib is tested. But 'make install' installs the version from blib/lib. And depending from your perl they are different. so you want Apache-Test to test _only_ the version in blib and _never_ the version in lib, right? this kinda confirms my suspicion that stas % env APACHE_TEST_LIVE_DEV=1 t/TEST -conf patch does exactly the opposite of what you wanted. I reported that to Stas and he explaind that the lib path is hardcoded to make development easier. for the record, I need to re-iterate how much I dislike that idea in the first place :) As a solution he suggest a ENV var that when set prefer the lib dir for development. so, what I gather is that what APACHE_TEST_LIVE_DEV=1 ought to do is not add lib to @INC, but rather ensure that lib is not used at all, thus forcing the tests to use blib (as is the standard practice everywhere I know about except Apache-Test). does that sound right? --Geoff
Re: A::T blib vs lib
Geoffrey Young wrote: That leads to different version of Apache:PageKit in the lib and blib/lib directories. With the current version of Apache::Test the version in lib is tested. But 'make install' installs the version from blib/lib. And depending from your perl they are different. so you want Apache-Test to test _only_ the version in blib and _never_ the version in lib, right? this kinda confirms my suspicion that stas % env APACHE_TEST_LIVE_DEV=1 t/TEST -conf patch does exactly the opposite of what you wanted. No, my patch does the right thing. It does not add 'lib' by default. It adds it only if APACHE_TEST_LIVE_DEV=1 is there. I reported that to Stas and he explaind that the lib path is hardcoded to make development easier. for the record, I need to re-iterate how much I dislike that idea in the first place :) For the record, it's that idea is now optional, so unfortunately you there is not much left to dislike ;) As a solution he suggest a ENV var that when set prefer the lib dir for development. so, what I gather is that what APACHE_TEST_LIVE_DEV=1 ought to do is not add lib to @INC, but rather ensure that lib is not used at all, thus forcing the tests to use blib (as is the standard practice everywhere I know about except Apache-Test). does that sound right? Forget the APACHE_TEST_LIVE_DEV=1 option. I added it for myself and others who want to develop against 'lib'. By default you don't need to do anything and you never get 'lib' autoinserted for you. __ 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: A::T blib vs lib
Geoffrey Young wrote: Stas Bekman wrote: Boris Zentner wrote: Hi, A test against my project show's no real difference at all. I applied the patch against Apache-Test-1.04 and I verified that my t/conf/modperl_inc.pl contain the desired lines. use lib '/tmp/ap_ex/blib/arch'; use lib '/tmp/ap_ex/blib/lib'; 1; Perfect. You are now talking about a different issue. If you look at t/conf/httpd.conf, t/conf/extra.conf is loaded before t/conf/modperl_startup.pl (which loads t/conf/modperl_inc.pl and t/conf/modperl_inc.pl) that's why you have this problem. What you want to do is to move all the code from the Perl sections in t/conf/extra.conf.in into t/conf/modperl_extra.pl, which is loaded after t/conf/modperl_inc.pl and you will be alright. or use t/conf/extra.last.conf.in instead of t/conf/extra.conf.in, which is probably an easier solution, as it allows you to maintain a httpd.conf style config. Yes, sorry, that's the right advise. Boris, do you mind subscribing to test-dev? otherwise we see only replies and never your posts unless they are addressed to one of us. I don't know what happened to the moderators and why posts aren't making through :( Please send email to [EMAIL PROTECTED] __ 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: RELEASE document
Geoffrey Young wrote: hi all in preparation for the upcoming 1.05 release, I'm going to create a RELEASE document in the Apache-Test directory. I've attached a preliminary version here, which is essentially copied from the one for mod_perl (with a few adjustments). if I'm missing anything or something isn't right, please speak up. if it's mostly right but easier to tweak via CVS, just let me know and I'll commit it. +1 with one comment below Instructions for Apache-Test Release Manager [...] 4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz) a. upload to www.apache.org:/www/perl.apache.org/dist/ b. remove releases older by 2 subversions (keep the last one) we don't release Apache-Test on apache.org, but only CPAN. So you can drop 4. The rest looks good. __ 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: RELEASE document
4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz) a. upload to www.apache.org:/www/perl.apache.org/dist/ b. remove releases older by 2 subversions (keep the last one) we don't release Apache-Test on apache.org, but only CPAN. So you can drop 4. http://perl.apache.org/dist/Apache-Test-1.04.tar.gz ? --Geoff
Re: RELEASE document
Geoffrey Young wrote: 4. Release the package and update links (e.g. mod_perl-1.99_11.tar.gz) a. upload to www.apache.org:/www/perl.apache.org/dist/ b. remove releases older by 2 subversions (keep the last one) we don't release Apache-Test on apache.org, but only CPAN. So you can drop 4. http://perl.apache.org/dist/Apache-Test-1.04.tar.gz Oops, blame the momentum, as I was releasing it and mod_perl at once. I've deleted that file from the above URL. Thanks for spotting it ;) __ 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: A::T blib vs lib
Hi, Am Dienstag, 21. Oktober 2003 14:19 schrieb Geoffrey Young: Stas Bekman wrote: Boris Zentner wrote: Hi, A test against my project show's no real difference at all. I applied the patch against Apache-Test-1.04 and I verified that my t/conf/modperl_inc.pl contain the desired lines. use lib '/tmp/ap_ex/blib/arch'; use lib '/tmp/ap_ex/blib/lib'; 1; Perfect. You are now talking about a different issue. If you look at t/conf/httpd.conf, t/conf/extra.conf is loaded before t/conf/modperl_startup.pl (which loads t/conf/modperl_inc.pl and t/conf/modperl_inc.pl) that's why you have this problem. What you want to do is to move all the code from the Perl sections in t/conf/extra.conf.in into t/conf/modperl_extra.pl, which is loaded after t/conf/modperl_inc.pl and you will be alright. or use t/conf/extra.last.conf.in instead of t/conf/extra.conf.in, which is probably an easier solution, as it allows you to maintain a httpd.conf style config. That was a very good hint. It allows me to keep the perl part into the apache directives as desired. But my @INC path is still wrong. Thanks for the Tip. --Geoff -- Boris
Re: A::T blib vs lib
Hi Geoffrey,
Am Dienstag, 21. Oktober 2003 15:09 schrieb Geoffrey Young:
That was a very good hint. It allows me to keep the perl part into the
apache directives as desired. But my @INC path is still wrong.
hmm.
ok, how about you show us a few things, like all of modperl_inc.pl, then
what directories you would like included that are missing. and also show
us your @INC.
My problem is if have a large project ( Apache::PageKit ) that works currently
with perl 5.6.1, perl 5.6.1 but 5.8 and perl = 5.8. Thats no problem,
but a newbie can not install it propper. So my intent is a installation
process that does a the right thing for the installed version of perl. Since
I prefer a automatic solution I test the version of perl and apply all needed
patches to Apache::PageKit during the 'make' phase. That leads to different
version of Apache:PageKit in the lib and blib/lib directories. With the
current version of Apache::Test the version in lib is tested. But 'make
install' installs the version from blib/lib. And depending from your perl
they are different.
I reported that to Stas and he explaind that the lib path is hardcoded to make
development easier. As a solution he suggest a ENV var that when set prefer
the lib dir for development.
Then Stas kindly produce a patch that I tested today against Apache::Test
1.04.
if the libraries are properly specified in modperl_inc.pl but not in @INC,
that's one thing. if they are not in modperl_inc.pl that's another. right
now, I'm unclear as to what the problem is exactly.
In short lib is searched before blib/lib. I had a workaround that overwrites
some routines in Apache::Test but it is really uggly and may not work taht
long. Im happy that Stas is now looking into the problem.
my modperl_onc.pl contains this lines:
## modperl_inc.pl
use lib '/tmp/ap_ex/blib/arch';
use lib '/tmp/ap_ex/blib/lib';
1;
# extra.last.conf.in
Location /
SetHandler perl-script
PerlSetVar PKIT_ROOT @ServerRoot@/../eg
PerlSetVar PKIT_SERVER staging
PerlHandler +Apache::PageKit
Perl
use Apache::PageKit;
Apache::PageKit-startup('@ServerRoot@/../eg','staging');
/Perl
/Location
and here is my @INC as you can see loaded from lib and not from blib/lib as
desired.
Can't locate Text/Iconv.pm in @INC (@INC contains: /tmp/ap_ex/Apache-Test/
lib /tmp/ap_ex/lib /tmp/ap_ex/blib/lib /tmp/ap_ex/blib/arch /home/ptest/lib/
perl5/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1 /home/ptest/lib/perl5/
site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/
site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/
site_perl/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/
lib/perl5/site_perl . /home/ptest/lib/perl5/5.8.1/i686-linux-thread-multi /
home/ptest/lib/perl5/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/
lib/perl5/site_perl .) at /tmp/ap_ex/lib/Apache/PageKit.pm line 21.
--Geoff
--
Boris
Re: A::T blib vs lib
Boris Zentner wrote:
[Finally the kind moderator let your messages through ;) Thank you!]
In short lib is searched before blib/lib. I had a workaround that overwrites
some routines in Apache::Test but it is really uggly and may not work taht
long. Im happy that Stas is now looking into the problem.
my modperl_onc.pl contains this lines:
## modperl_inc.pl
use lib '/tmp/ap_ex/blib/arch';
use lib '/tmp/ap_ex/blib/lib';
1;
which shows that '/tmp/ap_ex/lib' is no longer hardcoded in the server setup.
But...
# extra.last.conf.in
Location /
SetHandler perl-script
PerlSetVar PKIT_ROOT @ServerRoot@/../eg
PerlSetVar PKIT_SERVER staging
PerlHandler +Apache::PageKit
Perl
use Apache::PageKit;
Apache::PageKit-startup('@ServerRoot@/../eg','staging');
/Perl
/Location
and here is my @INC as you can see loaded from lib and not from blib/lib as
desired.
Can't locate Text/Iconv.pm in @INC (@INC contains: /tmp/ap_ex/Apache-Test/
lib /tmp/ap_ex/lib /tmp/ap_ex/blib/lib /tmp/ap_ex/blib/arch /home/ptest/lib/
perl5/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/5.8.1 /home/ptest/lib/perl5/
site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/
site_perl/5.8.1/i686-linux-thread-multi /home/ptest/lib/perl5/
site_perl/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/
lib/perl5/site_perl . /home/ptest/lib/perl5/5.8.1/i686-linux-thread-multi /
home/ptest/lib/perl5/5.8.1 /home/ptest/lib/perl5/site_perl/5.8.1/
i686-linux-thread-multi /home/ptest/lib/perl5/site_perl/5.8.1 /home/ptest/
lib/perl5/site_perl .) at /tmp/ap_ex/lib/Apache/PageKit.pm line 21.
Found it. The autogenerated t/TEST was also pushing lib into @INC, will fix
that shortly.
__
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: A::T blib vs lib
Hi,
im subscribed!
All your hints and tips bring me a step forward, but I stuck on the @INC
again. Even with the patch.
The only thing that pass my brief tests is to change the order of the included
path inside TestConfig.pm
--- TestConfig.pm.orig 2003-10-21 20:49:53.0 +0200
+++ TestConfig.pm 2003-10-21 20:51:20.0 +0200
@@ -1441,7 +1441,7 @@
# followed by modperl-2.0/lib (or some other project's lib/),
# followed by blib/ and finally system-wide libs.
lib::-import(map $self-{vars}-{top_dir}/$_,
- qw(Apache-Test/lib lib blib/lib blib/arch));
+ qw(Apache-Test/lib blib/arch blib/lib lib));
#print join \n, add_inc, @INC, ;
}
Am Dienstag, 21. Oktober 2003 18:12 hast Du geschrieben:
Geoffrey Young wrote:
Stas Bekman wrote:
Boris Zentner wrote:
Hi,
A test against my project show's no real difference at all. I applied
the patch against Apache-Test-1.04 and I verified that my
t/conf/modperl_inc.pl contain the desired lines.
use lib '/tmp/ap_ex/blib/arch';
use lib '/tmp/ap_ex/blib/lib';
1;
Perfect. You are now talking about a different issue. If you look at
t/conf/httpd.conf, t/conf/extra.conf is loaded before
t/conf/modperl_startup.pl (which loads t/conf/modperl_inc.pl and
t/conf/modperl_inc.pl) that's why you have this problem. What you want
to do is to move all the code from the Perl sections in
t/conf/extra.conf.in into t/conf/modperl_extra.pl, which is loaded
after t/conf/modperl_inc.pl and you will be alright.
or use t/conf/extra.last.conf.in instead of t/conf/extra.conf.in, which
is probably an easier solution, as it allows you to maintain a
httpd.conf style config.
Yes, sorry, that's the right advise.
Boris, do you mind subscribing to test-dev? otherwise we see only replies
and never your posts unless they are addressed to one of us. I don't know
what happened to the moderators and why posts aren't making through :(
Please send email to [EMAIL PROTECTED]
__
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
--
Boris
New Flood diff to handle 100 continue when in first chunk, and next packet available [Ref A5]
The new patch is the first step towards Flood handling 100 continue
responses. If such response is found in the first chunk read, and the
next response is also available there already, then we read past the 100
message and read in the next message's headers and body if available.
Please evaluate the attached diff file and incorporate into the
flood_socket_keepalive.c file in CVS. I have made the diff off the build
1.1 version and not off my own previous changes since this is an
independent change.
-Norman Tuttle, developer, OpenDemand Systems, [EMAIL PROTECTED]
--- flood_socket_keepalive.c2003-10-21 13:42:43.0 -0400
+++ \flood-1.1\flood_socket_keepalive.c 2003-09-06 00:27:38.0 -0400
@@ -241,7 +241,7 @@
return status;
}
-/* We got caught in the middle of a chunk last time. */
+/* We got caught in the middle of a chunk last time. */
if (old_length 0) {
b -= old_length;
blen += old_length;
@@ -307,7 +307,7 @@
return APR_SUCCESS;
}
-static apr_status_t keepalive_load_resp(response_t *resp,
+static apr_status_t keepalive_load_resp(response_t *resp,
keepalive_socket_t *sock,
apr_size_t remaining, apr_pool_t *pool)
{
@@ -360,20 +360,12 @@
cp += i;
remaining -= i;
}
-while (status != APR_EGENERAL status != APR_EOF
+while (status != APR_EGENERAL status != APR_EOF
status != APR_TIMEUP (!remain || remaining));
return status;
}
-enum
-{
- FIRST_LINE,
- FIRST_LINE_AFTER_100,
- AFTER_FIRST_LINE,
- AFTER_100
-};
-
/**
* Keep-alive implementation for recv_resp.
*/
@@ -382,7 +374,6 @@
keepalive_socket_t *ksock = (keepalive_socket_t *)sock;
char *cl, *ecl, cls[17];
char *current_line;
-int readstate = FIRST_LINE;
int i;
response_t *new_resp;
apr_status_t status;
@@ -408,16 +399,7 @@
int line_length, key_length;
end_of_line = strstr(current_line, CRLF);
-if (!end_of_line) break;
-if (readstate AFTER_FIRST_LINE)
readstate=((strncasecmp(current_line, HTTP/1.1 100,
12))?AFTER_FIRST_LINE:AFTER_100);
-if (end_of_line == current_line)
-{
-if (readstate == AFTER_100)
-{
- current_line += 2; // Add 2 characters to pass the CRLF
=strlen(CRLF).
- readstate = FIRST_LINE_AFTER_100;
- continue;
-}
+if (!end_of_line || end_of_line == current_line) {
break;
}
line_length = end_of_line - current_line;
@@ -425,7 +407,7 @@
header_end = memchr(current_line, ':', line_length);
if (header_end) {
key_length = header_end - current_line;
-
+
header_key = apr_pstrmemdup(pool, current_line, key_length);
header_val = apr_pstrmemdup(pool, current_line + key_length + 2,
line_length - key_length - 2);
@@ -438,10 +420,10 @@
/* If this exists, we aren't keepalive anymore. */
header = apr_table_get(new_resp-headers, Connection);
if (header !strcasecmp(header, Close)) {
-new_resp-keepalive = 0;
+new_resp-keepalive = 0;
}
else {
-new_resp-keepalive = 1;
+new_resp-keepalive = 1;
}
/* If we have a HEAD request, we shouldn't be receiving a body. */
@@ -467,7 +449,7 @@
/* We have a partial chunk and we aren't at the end. */
if (cl *cl (cl - (char*)new_resp-rbuf) new_resp-rbufsize) {
int remaining;
-
+
do {
if (new_resp-chunk) {
/* If we have enough space to skip over the ending CRLF,
@@ -494,8 +476,8 @@
foo = strstr(new_resp-chunk, CRLF);
assert(foo);
new_resp-chunk = foo + 2;
-remaining = new_resp-rbufsize -
-(int)(new_resp-chunk -
+remaining = new_resp-rbufsize -
+(int)(new_resp-chunk -
(char*)new_resp-rbuf);
}
else {
@@ -513,7 +495,7 @@
header = apr_table_get(new_resp-headers, Content-Length);
if (!header)
{
-new_resp-keepalive = 0;
+new_resp-keepalive = 0;
}
if (header)
@@ -526,7 +508,7 @@
cls[ecl-cl] = '\0';
content_length = strtol(cls, ecl, 10);
if (*ecl != '\0')
-new_resp-keepalive = 0;
+new_resp-keepalive = 0;
}
}
@@ -537,14 +519,14 @@
Re: A::T blib vs lib
Boris Zentner wrote:
Hi,
im subscribed!
And someone has let your previous posts through ;)
All your hints and tips bring me a step forward, but I stuck on the @INC
again. Even with the patch.
The only thing that pass my brief tests is to change the order of the included
path inside TestConfig.pm
--- TestConfig.pm.orig 2003-10-21 20:49:53.0 +0200
+++ TestConfig.pm 2003-10-21 20:51:20.0 +0200
@@ -1441,7 +1441,7 @@
# followed by modperl-2.0/lib (or some other project's lib/),
# followed by blib/ and finally system-wide libs.
lib::-import(map $self-{vars}-{top_dir}/$_,
- qw(Apache-Test/lib lib blib/lib blib/arch));
+ qw(Apache-Test/lib blib/arch blib/lib lib));
#print join \n, add_inc, @INC, ;
}
There were two more places where lib was unconditionally pushed. And removing
lib, affected mod_perl 2, so I had to fix that as well. I haven't thoroughly
tested this change yet, but please try this patch:
Index: lib/Apache/TestConfig.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.179
diff -u -r1.179 TestConfig.pm
--- lib/Apache/TestConfig.pm 20 Oct 2003 22:48:58 - 1.179
+++ lib/Apache/TestConfig.pm 21 Oct 2003 19:28:50 -
@@ -120,7 +120,7 @@
sub server { shift-{server} }
sub modperl_2_inc_fixup {
-(IS_MOD_PERL_2 !IS_MOD_PERL_2_BUILD) ? use Apache2;\n : '';
+(IS_MOD_PERL_2 ) ? use Apache2;\n : '';
}
sub modperl_build_config {
@@ -780,13 +780,19 @@
require FindBin;
-# the live 'lib/' dir of the distro (e.g. modperl-2.0/ModPerl-Registry/lib)
-my @dirs = canonpath catdir $FindBin::Bin, lib;
+my @dirs = ();
-# the live dir of the top dir if any (e.g. modperl-2.0/lib)
-if (-e catfile($FindBin::Bin, .., Makefile.PL)
--d catdir($FindBin::Bin, .., lib) ) {
-push @dirs, canonpath catdir $FindBin::Bin, .., lib;
+if ($ENV{APACHE_TEST_LIVE_DEV}) {
+# the live 'lib/' dir of the distro
+# (e.g. modperl-2.0/ModPerl-Registry/lib)
+my $dir = canonpath catdir $FindBin::Bin, lib;
+push @dirs, $dir if -d $dir;
+
+# the live dir of the top dir if any (e.g. modperl-2.0/lib)
+if (-e catfile($FindBin::Bin, .., Makefile.PL)) {
+my $dir = canonpath catdir $FindBin::Bin, .., lib;
+push @dirs, $dir if -d $dir;
+}
}
for (qw(. ..)) {
@@ -1442,8 +1448,18 @@
# make sure that Apache-Test/lib will be first in @INC,
# followed by modperl-2.0/lib (or some other project's lib/),
# followed by blib/ and finally system-wide libs.
-lib::-import(map $self-{vars}-{top_dir}/$_,
- qw(Apache-Test/lib lib blib/lib blib/arch));
+my $top_dir = $self-{vars}-{top_dir};
+my @dirs = map { catdir $top_dir, blib, $_ } qw(lib arch);
+
+my $apache_test_dir = catdir $top_dir, Apache-Test;
+unshift @dirs, $apache_test_dir if -d $apache_test_dir;
+
+if ($ENV{APACHE_TEST_LIVE_DEV}) {
+my $lib_dir = catdir $top_dir, lib;
+push @dirs, $lib_dir if -d $lib_dir;
+}
+
+lib::-import(@dirs);
#print join \n, add_inc, @INC, ;
}
Index: lib/Apache/TestConfigPerl.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigPerl.pm,v
retrieving revision 1.78
diff -u -r1.78 TestConfigPerl.pm
--- lib/Apache/TestConfigPerl.pm 20 Oct 2003 20:22:56 - 1.78
+++ lib/Apache/TestConfigPerl.pm 21 Oct 2003 19:28:50 -
@@ -153,7 +153,6 @@
if (my $inc = $self-{inc}) {
my $include_pl = catfile $self-{vars}-{t_conf}, 'modperl_inc.pl';
my $fh = $self-genfile($include_pl);
-# make sure that the dev libs come before blib
for (reverse @$inc) {
print $fh use lib '$_';\n;
}
__
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: A::T blib vs lib
Hi Stas, It works fine. Thanks. There were two more places where lib was unconditionally pushed. And removing lib, affected mod_perl 2, so I had to fix that as well. I haven't thoroughly tested this change yet, but please try this patch: [...] __ 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 -- Boris
Re: A::T blib vs lib
Stas Bekman wrote: I haven't thoroughly tested this change yet, but please try this patch: tests fine for me on mp2 and my 3rd party apps. nice work. --Geoff
Re: A::T blib vs lib
Geoffrey Young wrote: Stas Bekman wrote: I haven't thoroughly tested this change yet, but please try this patch: tests fine for me on mp2 and my 3rd party apps. nice work. There are problems if you remove previously installed modperl. I'm looking at it. __ 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: A::T blib vs lib
Stas Bekman wrote: Geoffrey Young wrote: tests fine for me on mp2 and my 3rd party apps. Thanks Geoff. There are problems if you remove previously installed modperl. I'm looking at it. Apparently mod_perl 2.0's distro must have 'lib' pushed onto @INC from t/TEST. That was the problem. Now committed with the special case for mod_perl build. Please verify that it works for you Boris and we will make a new release. Geoff has volunteered to be the release manager for this release. ;) __ 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
Can't use handler + reverse proxy
Hi, I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. any ideas ? Matthieu
Re: Can't use handler + reverse proxy
Matthieu Estrade wrote: I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. any ideas ? IMHO, in teh reverse proxy case, the handler is mod_proxy. You'll have to solve this some other way I think. What exactly are you trying to accomplish with your handler? -- ir. Kris Verbeeck Software Engineer Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium T: +32 16 28 70 64 F: +32 16 28 70 77 Ubizen - We Secure e-business - www.ubizen.com
Re: Can't use handler + reverse proxy
On Tue, 21 Oct 2003, Matthieu Estrade wrote: I am actually using apache as a reverse proxy, and i am trying to use a handler with... and it doesn't work. When i setup my SetHandler on a local virtualhost, it works well, but when i setup it on a virtualhost doing reverse proxy, it's never called. A handler is intended to generate content, whereas with a reverse proxy the content comes from the backend server. Thus the two concepts are mutually exclusive. What exactly are you trying to do, and with what version of apache? --Cliff
Re: Can't use handler + reverse proxy
I am using Apache 2.0 and what i want to do is a applicative authentication using a form i wanted sent by the reverse proxy. But i think i will do another way, looking into mod_mem_cache how it's disable mod_proxy when it want to serve data directly from his cache... Cliff Woolley wrote: On Tue, 21 Oct 2003, Cliff Woolley wrote: What exactly are you trying to do, and with what version of apache? Wait a minute, let me guess. You're trying to serve up a .cgi script or a .php file or something similar as source code from the backend and then execute/interpret it on the proxy by way of a handler. Yeah, you can't do that. :) As has been pointed out, mod_proxy is taking the role of the handler here, and you can only have one. --Cliff
Re: Can't use handler + reverse proxy
I have to look what this quick handler do exactly, but i work well and seems to be able to act as normal handler. ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST); Cliff Woolley wrote: On Tue, 21 Oct 2003, Cliff Woolley wrote: What exactly are you trying to do, and with what version of apache? Wait a minute, let me guess. You're trying to serve up a .cgi script or a .php file or something similar as source code from the backend and then execute/interpret it on the proxy by way of a handler. Yeah, you can't do that. :) As has been pointed out, mod_proxy is taking the role of the handler here, and you can only have one. --Cliff
Re: Can't use handler + reverse proxy
On Tue, 21 Oct 2003, Matthieu Estrade wrote: I have to look what this quick handler do exactly, but i work well and seems to be able to act as normal handler. ap_hook_quick_handler(cache_url_handler, NULL, NULL, APR_HOOK_FIRST); Be careful there... the quick handler bypasses a whole lot of stuff. I don't remember details, but be absolutely sure it's doing exactly what you want if you're going to use it. I don't understand why you're not writing a filter? --Cliff
Re: Can't use handler + reverse proxy
* Matthieu Estrade [EMAIL PROTECTED] wrote: I could do with a filter but i need to place it before authentication hook... I have just finished what i wanted to do: The quick handler is controlling if the user is already authenticated (cookie based or session table) Hmm. You could hook into the access or authentication hook, which is the appropriate place for such things. nd
RE: ap_invoke_handler
-Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] [...] Do not attempt to remove a filter once it's inserted, simple force it to be inert. Serveral Apache filters already do this, although I can't name one offhand (SSL might be, I think.) Perhaps I am just missing something, but is there something wrong in removing a filter, perhaps by itself, using ap_remove_input/output_filter() -- Sami Tikka, senior software engineer, F-Secure Corporation tel: +358 9 2520 5115, fax: +358 9 2520 5015 http://www.F-Secure.com F-Secure: Securing the Mobile Enterprise
Re: Any votes on this??
William A. Rowe, Jr. wrote: On Mon, 20 Oct 2003, Jim Jagielski wrote: * isn't ap_die() broken with recognizing recursive errors Have you had a chance to run it through the perl-framework testsuite? If so I'd give it +.5. Does the perl test suite check error handling at all? (just curious) Greg
Re: ap_invoke_handler
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's inserted, simple force it to be inert.
hmmm?
modules/http/http_protocol.c:: ap_byterange_filter()
/* We have nothing to do, get out of the way. */
if (num_ranges == 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
Greg
RE: ap_invoke_handler
At 06:06 AM 10/21/2003, Tikka, Sami wrote: -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] [...] Do not attempt to remove a filter once it's inserted, simple force it to be inert. Serveral Apache filters already do this, although I can't name one offhand (SSL might be, I think.) Perhaps I am just missing something, but is there something wrong in removing a filter, perhaps by itself, using ap_remove_input/output_filter() Once *one* byte of data has passed through a given filter within the filter chain, you cannot know if one filter is sitting on bytes of request or response body that it is waiting for completion. Maybe it has a partial token stored, maybe it's an incomplete multibyte sequence for a given code page translation. In both cases, once a byte is inside the filter chain, during a request (this is what I'm assuming your module does) you cannot add and drop filters. In my input filter, I don't pass ANY data on until I am sure all the filter processing is done (the filter is only inserted selectively). What would be wrong with calling remove_filter then? It was inserted when required, and when I'm ready to return (and pass some data on), remove the filter I just inserted. Those APIs are used for changing the filters before the request is processed. --- Aryeh Katz Secured-Services Inc.
Re: ap_invoke_handler
At 09:51 AM 10/21/2003, [EMAIL PROTECTED] wrote:
William A. Rowe, Jr. wrote:
At 03:17 PM 10/20/2003, Aryeh Katz wrote:
I have an input filter that might need to reinvoke the handler that inserted this
input filter (this time with the filter removed).
Do not attempt to remove a filter once it's inserted, simple force it to be inert.
hmmm?
Ahhh. Now look at the code below. WHO removes the byterange filter?
Answer, the byterange filter removes itself. It *knows* there are no partially
processed buckets that it is holding on to. Nobody else is allowed to add
or remove a filter - but the filter may remove itself when it knows this is
a safe operation.
Be careful here, by the way. We have to be certain that f itself isn't
modified, such that the next reference of f-next isn't corrupted. That
won't occur in 2.0.x. Hopefully 2.1-dev retains that behavior, but for
safetys sake, this code would be better if you dereferenced f-next
and saved it, then called remove, the passed the saved reference.
Somewhat pedantic but it seems cleaner to me.
Bill
modules/http/http_protocol.c:: ap_byterange_filter()
/* We have nothing to do, get out of the way. */
if (num_ranges == 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
Greg
Re: ap_invoke_handler
At 12:45 PM 10/21/2003, André Malo wrote: * William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Answer, the byterange filter removes itself. It *knows* there are no partially processed buckets that it is holding on to. Nobody else is allowed to add or remove a filter - but the filter may remove itself when it knows this is a safe operation. Sorry Bill, that doesn't match the reality. Think of AddOutputFilterByType and a content-type changing filter module (PHP output filter, for example). The core triggers a filter insertation for *every* content-type change. And - actually, this can be quite useful (again, think of PHP. The script may return different content types). All of the by-type filter changes occur BEFORE bytes start passing. I read this request as the possibility that the user was trying to modify the list of filters after some filtering had started. The part that had me most concerned was removing the filter, which is dangerous after filtering begins, for the reasons I mentioned before. Of course you can add and remove filters however you like before we actually process the request :) Sorry for any confusion. Bill
Re: ap_invoke_handler
Ahhh. Now look at the code below. WHO removes the byterange filter? Answer, the byterange filter removes itself. That's perfectly clear, and it's common practice. I (and evidently others) read your previous post as disallowing that, causing a raised eyebrow. It *knows* there are no partially processed buckets that it is holding on to. Nobody else is allowed to add or remove a filter - but the filter may remove itself when it knows this is a safe operation. May I humbly submit there are other perfectly safe situations: (1) Any filter in its filter_init phase can remove another filter (some of my output filters remove the Content-Length filter - as it was causing bogus results on HEAD requests). (2) In the main loop, a filter can remove another from later in the chain before any data have been passed through. (3) Where another filter's behavious is known to be safe (mod_diagnostics filters can be removed at any time). -- Nick Kew
Re: ap_invoke_handler
At 03:43 PM 10/21/2003, Nick Kew wrote: Ahhh. Now look at the code below. WHO removes the byterange filter? Answer, the byterange filter removes itself. That's perfectly clear, and it's common practice. I (and evidently others) read your previous post as disallowing that, causing a raised eyebrow. It *knows* there are no partially processed buckets that it is holding on to. Nobody else is allowed to add or remove a filter - but the filter may remove itself when it knows this is a safe operation. May I humbly submit there are other perfectly safe situations: (1) Any filter in its filter_init phase can remove another filter (some of my output filters remove the Content-Length filter - as it was causing bogus results on HEAD requests). (2) In the main loop, a filter can remove another from later in the chain before any data have been passed through. (3) Where another filter's behavious is known to be safe (mod_diagnostics filters can be removed at any time). Great summary :) However, number (3) use some caution. Although you think that the DIAGNOSTIC filter behaves a certain way, the next upgrade by the author might introduce new considerations. Bill
