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 "Christopher H. Laco" <ap...@chrislaco.com> on 2004/12/02 02:16:17 UTC
[PATCH] Test & TestRequest pod
OK, I'm a programmer, not a writer. Be gentle.
Nothing major, just the a mention of cookie_jar and additional headers
via the second param in GET (and probably others?).
While I was at it, I made sure all of the need* examples were all the
same; which meant removing \& and &. The bare versions seemed to be the
most prevelant.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>> Stas Bekman wrote:
>>
>>> Still someone needs to do the work and verify that things are working.
>>
>>
>>
>> That will fun in and of itself. Right now, the only thing close to
>> meeting the requirements of running the overall tests is my 5.6.1
>> install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03.
>>
>> It'll probably take some time just to get my unmodded working copy to
>> run all of it's test before I even start coding.
>>
>> I may just have to whip up another FBSD tinker box.
>>
>> -=Chris
>>
>>
> And so it starts. I'm having problems subscribing to the modperl-win32
> list at the moment, otherwise I'd ask this there.
I had no idea such list exists.
> Is there any other way
> to test my changes other than trying to build mp2 itself?
Probably not, since it relies on the fact that it has an access to the source.
> I want to get started on the changes but I can get mp2 to build on Win32:
>
> Configure mod_perl with C:\Development\Apache2? [y]
> Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4
> Note (probably harmless): No library found for /lib/libapr.lib
>
> Of course, my %LIB% contains the appropriate Apache2/lib directory and
> that dir is also in my Config.pm.
>
> Thanks for putting up with the newb.
Please post this question to the modperl-dev list (with a relevant subject):
http://perl.apache.org/maillist/dev.html
and Randy will be able to help you. (I'm of no help on win32)
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> Still someone needs to do the work and verify that things are working.
>
>
> That will fun in and of itself. Right now, the only thing close to
> meeting the requirements of running the overall tests is my 5.6.1
> install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03.
>
> It'll probably take some time just to get my unmodded working copy to
> run all of it's test before I even start coding.
>
> I may just have to whip up another FBSD tinker box.
>
> -=Chris
>
>
And so it starts. I'm having problems subscribing to the modperl-win32
list at the moment, otherwise I'd ask this there. Is there any other way
to test my changes other than trying to build mp2 itself?
I want to get started on the changes but I can get mp2 to build on Win32:
Configure mod_perl with C:\Development\Apache2? [y]
Configuring Apache/2.0.52 mod_perl/1.99_18-dev Perl/v5.8.4
Note (probably harmless): No library found for /lib/libapr.lib
Of course, my %LIB% contains the appropriate Apache2/lib directory and
that dir is also in my Config.pm.
Thanks for putting up with the newb.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Stas Bekman wrote:
> Still someone needs to do the work and verify that things are working.
That will fun in and of itself. Right now, the only thing close to
meeting the requirements of running the overall tests is my 5.6.1
install on my XP lappy. Both of my FreeBSD boxen are still 5.005_03.
It'll probably take some time just to get my unmodded working copy to
run all of it's test before I even start coding.
I may just have to whip up another FBSD tinker box.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> > Of course it should take the necessary precautions for when / is and
>> > isn't included, etc.
>>
>> What do you mean? Examples?
>>
>
> Well, let's go with the running sample:
>
> sub module2url {
> my $module = shift;
> my $scheme = shift || "http";
>
> Apache::TestRequest::module($module);
> my $config = Apache::Test::config();
> my $hostport = Apache::TestRequest::hostport($config);
> my $path = Apache::TestRequest::module2path($module);
> return "$scheme://$hostport$path";
> }
>
> If looks as though module2path() returns the path starting with /.
> If we override that with the path from the hashref module2url($url,
> {path => 'mypath'}) we would end up with scheme://host:portmypath
> instead of scheme://host:port/mypath.
You are correct. Then yes, if the $path argument is provided by the user
strip the leading /.
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Stas Bekman wrote:
> > Of course it should take the necessary precautions for when / is and
> > isn't included, etc.
>
> What do you mean? Examples?
>
Well, let's go with the running sample:
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return "$scheme://$hostport$path";
}
If looks as though module2path() returns the path starting with /.
If we override that with the path from the hashref module2url($url,
{path => 'mypath'}) we would end up with scheme://host:portmypath
instead of scheme://host:port/mypath.
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>>>> I think all kind of refactoring would be great. One thing I wanted
>>>> to do for tests again vhosts, is to add this function next to
>>>> module2path():
>>>>
>>>> sub module2url {
>>>> my $module = shift;
>>>> my $scheme = shift || "http";
>>>>
>>>> Apache::TestRequest::module($module);
>>>> my $config = Apache::Test::config();
>>>> my $hostport = Apache::TestRequest::hostport($config);
>>>> my $path = Apache::TestRequest::module2path($module);
>>>> return "$scheme://$hostport$path";
>>>> }
>>>>
>>>> and then replace the long craft used a lot in the modperl tests, so
>>>> now one can write a simple:
>>>>
>>>> my $module = "Foo::bar";
>>>> {
>>>> my $path = Apache::TestRequest::module2path($module);
>>>> GET $path; # GET "/Foo__bar"
>>>> }
>>>> {
>>>> my $url = Apache::TestRequest::module2url($module);
>>>> GET $url; # GET "http://localhost:8545/Foo__bar"
>>>> }
>
>
> After another look at things like t/merge.t, it looks like there are at
> least 2 different use cases for module2perl.
>
> 1) The $module sent to module2perl will be sent to ::module() and will
> be the same as the path. This is your first example:
>
> Foo::Bar => /Foo__Bar
>
> 2) The $module sent to module2perl will be sent to ::module(), but a
> DIFFERENT path is required; like in merge3.t where the path ==
> '/merge3/ != TestModperl::merge
>
> What about make mopdeul2url have a hashref as the second arg in which we
> can override $path, and of course $scheme
>
> Apache::TestRequest::module2path('TestModePerl::merge', {
> scheme => 'https',
> path => '/merge3/
> }
Isn't merge3 an odd ball? Originally I was thinking to do the refactoring
for the code which identical and leave the more complex cases alone. But
if you wish to implement the suggested functionality go for it. It
definitely makes the test more readable, and those wishing to use the old
functionality still can do that.
though it's module2url, not module2path (saw your update)
> Of course it should take the necessary precautions for when / is and
> isn't included, etc.
What do you mean? Examples?
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Of of course, I meant t/modperl/merge.t and module2url
Got perl on the brain.
> After another look at things like t/merge.t, it looks like there are at
> least 2 different use cases for module2perl.
>
> 1) The $module sent to module2perl will be sent to ::module() and will
> be the same as the path. This is your first example:
>
> Foo::Bar => /Foo__Bar
>
> 2) The $module sent to module2perl will be sent to ::module(), but a
> DIFFERENT path is required; like in merge3.t where the path ==
> '/merge3/ != TestModperl::merge
>
> What about make mopdeul2url have a hashref as the second arg in which we
> can override $path, and of course $scheme
>
> Apache::TestRequest::module2path('TestModePerl::merge', {
> scheme => 'https',
> path => '/merge3/
> }
>
> Of course it should take the necessary precautions for when / is and
> isn't included, etc.
>
> -=Chris
>
>
Re: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Stas Bekman wrote:
>>> I think all kind of refactoring would be great. One thing I wanted to
>>> do for tests again vhosts, is to add this function next to
>>> module2path():
>>>
>>> sub module2url {
>>> my $module = shift;
>>> my $scheme = shift || "http";
>>>
>>> Apache::TestRequest::module($module);
>>> my $config = Apache::Test::config();
>>> my $hostport = Apache::TestRequest::hostport($config);
>>> my $path = Apache::TestRequest::module2path($module);
>>> return "$scheme://$hostport$path";
>>> }
>>>
>>> and then replace the long craft used a lot in the modperl tests, so
>>> now one can write a simple:
>>>
>>> my $module = "Foo::bar";
>>> {
>>> my $path = Apache::TestRequest::module2path($module);
>>> GET $path; # GET "/Foo__bar"
>>> }
>>> {
>>> my $url = Apache::TestRequest::module2url($module);
>>> GET $url; # GET "http://localhost:8545/Foo__bar"
>>> }
After another look at things like t/merge.t, it looks like there are at
least 2 different use cases for module2perl.
1) The $module sent to module2perl will be sent to ::module() and will
be the same as the path. This is your first example:
Foo::Bar => /Foo__Bar
2) The $module sent to module2perl will be sent to ::module(), but a
DIFFERENT path is required; like in merge3.t where the path ==
'/merge3/ != TestModperl::merge
What about make mopdeul2url have a hashref as the second arg in which we
can override $path, and of course $scheme
Apache::TestRequest::module2path('TestModePerl::merge', {
scheme => 'https',
path => '/merge3/
}
Of course it should take the necessary precautions for when / is and
isn't included, etc.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> Christopher H. Laco wrote:
>>
>>> On that note, what else can I work on?
>>> Apparently I'm a glutton for punishment.
>>
>>
>>
>> Not sure, there are all kind of things in the ToDo file, but they all
>> mostly obscure.
>>
>> I think all kind of refactoring would be great. One thing I wanted to
>> do for tests again vhosts, is to add this function next to module2path():
>>
>> sub module2url {
>> my $module = shift;
>> my $scheme = shift || "http";
>>
>> Apache::TestRequest::module($module);
>> my $config = Apache::Test::config();
>> my $hostport = Apache::TestRequest::hostport($config);
>> my $path = Apache::TestRequest::module2path($module);
>> return "$scheme://$hostport$path";
>> }
>>
>> and then replace the long craft used a lot in the modperl tests, so
>> now one can write a simple:
>>
>> my $module = "Foo::bar";
>> {
>> my $path = Apache::TestRequest::module2path($module);
>> GET $path; # GET "/Foo__bar"
>> }
>> {
>> my $url = Apache::TestRequest::module2url($module);
>> GET $url; # GET "http://localhost:8545/Foo__bar"
>> }
>>
>> grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
>> talking about.
>>
>>
>>
> Hmmm, sounds easy enough since you already included module2url. :-)
> Famous last words.
Still someone needs to do the work and verify that things are working.
> Is this just a concern in t/modperl? I came up with 77 hits in t/, and
> 11 of those are in t/modperl. Maybe that small subset is a same place
> for me to start.
It's all t/. But you can start with a subset.
> Am I correct in assuming that the modperl in SVN is the 2.0 trunk (the
> one I want) and that 1.0 is stuck back in CVS? I'm still trying to wrap
> my brainpan around what modules are where and what perl-framework really
> encompasses.
That's correct. I tried to argue that we want it to be called modperl-2.0,
but the httpd-way was preferrable on other developers.
The online docs have all the info:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Stas Bekman wrote:
> Christopher H. Laco wrote:
>
>> On that note, what else can I work on?
>> Apparently I'm a glutton for punishment.
>
>
> Not sure, there are all kind of things in the ToDo file, but they all
> mostly obscure.
>
> I think all kind of refactoring would be great. One thing I wanted to do
> for tests again vhosts, is to add this function next to module2path():
>
> sub module2url {
> my $module = shift;
> my $scheme = shift || "http";
>
> Apache::TestRequest::module($module);
> my $config = Apache::Test::config();
> my $hostport = Apache::TestRequest::hostport($config);
> my $path = Apache::TestRequest::module2path($module);
> return "$scheme://$hostport$path";
> }
>
> and then replace the long craft used a lot in the modperl tests, so now
> one can write a simple:
>
> my $module = "Foo::bar";
> {
> my $path = Apache::TestRequest::module2path($module);
> GET $path; # GET "/Foo__bar"
> }
> {
> my $url = Apache::TestRequest::module2url($module);
> GET $url; # GET "http://localhost:8545/Foo__bar"
> }
>
> grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
> talking about.
>
>
>
Hmmm, sounds easy enough since you already included module2url. :-)
Famous last words.
Is this just a concern in t/modperl? I came up with 77 hits in t/, and
11 of those are in t/modperl. Maybe that small subset is a same place
for me to start.
Am I correct in assuming that the modperl in SVN is the 2.0 trunk (the
one I want) and that 1.0 is stuck back in CVS? I'm still trying to wrap
my brainpan around what modules are where and what perl-framework really
encompasses.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> On that note, what else can I work on?
> Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || "http";
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return "$scheme://$hostport$path";
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = "Foo::bar";
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET "/Foo__bar"
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET "http://localhost:8545/Foo__bar"
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Stas Bekman wrote:
> No, no, the root of A-T. An example will be more useful:
>
> --- lib/Apache/Test.pm (revision 109410)
> +++ lib/Apache/Test.pm (working copy)
>
> I can chdir into the root of the project and apply your patch immediately.
Understood. Makes sense.
> Agreed, but dups are evil from the maintenance point of view. I'd rather
> have everything in one place and have the other document link to the
> first one. Unfortunately A-T pods are nowhere on perl.apache.org.
>
>> Were you looking for something more extensive?
>
>
> No, no, it's perfectly fine. The next person looking for the same
> solution will most likely easily find it.
>
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
-=Chris
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> Stas Bekman wrote:
>
>> Christopher H. Laco wrote:
>>
>>> OK, I'm a programmer, not a writer. Be gentle.
>>> Nothing major, just the a mention of cookie_jar and additional
>>> headers via the second param in GET (and probably others?).
>>>
>>> While I was at it, I made sure all of the need* examples were all the
>>> same; which meant removing \& and &. The bare versions seemed to be
>>> the most prevelant.
>>
>>
>>
>> Thanks Chris, commited. But see below.
>>
>> Also in the future please try to post diffs against the root of the
>> project so it's easier to apply those. Thanks.
>
>
> I assume you mean http://svn.apache.org/repos/asf/httpd/test/trunk/, and
> not just the root of Apache-Test correct?
No, no, the root of A-T. An example will be more useful:
--- lib/Apache/Test.pm (revision 109410)
+++ lib/Apache/Test.pm (working copy)
I can chdir into the root of the project and apply your patch immediately.
>>> Index: TestRequest.pm
>>> + Apache::TestRequest::user_agent(reset =>,
>>> + cookie_jar => {});
>>
>>
>>
>> Sorry, but what's that 'reset => ' thing? I've committed just:
>>
>> Apache::TestRequest::user_agent(cookie_jar => {});
>>
>> as in the test.
>
>
> Geez. Apparently I'm in the clouds this week. Maybe I need to do these
> changes during the day instead of at night. :-/
:)
>>> =head1 FUNCTIONS
>>>
>>> C<Apache::TestRequest> exports a number of functions that will likely
>>> @@ -837,6 +850,11 @@
>>> Sends a simple GET request to the Apache test server. Returns an
>>> C<HTTP::Response> object.
>>>
>>> +You can also supply additional headers to be sent with the request
>>> +by adding their name/value pairs after the C<url> parameter:
>>
>>
>>
>> really it's a dup of the more extensive docs at:
>> http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
>
>
>
> Well, yes, and that was on purpose. I hated reading the A-T pod and
> never knowing there was an extra param for GET. THe pod usualy is enough
> to get start, and I wouldn't exptec to have to read:
>
> http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Agreed, but dups are evil from the maintenance point of view. I'd rather
have everything in one place and have the other document link to the first
one. Unfortunately A-T pods are nowhere on perl.apache.org.
> Were you looking for something more extensive?
No, no, it's perfectly fine. The next person looking for the same solution
will most likely easily find it.
--
__________________________________________________________________
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: [PATCH] Test & TestRequest pod
Posted by "Christopher H. Laco" <ap...@chrislaco.com>.
Stas Bekman wrote:
> Christopher H. Laco wrote:
>
>> OK, I'm a programmer, not a writer. Be gentle.
>> Nothing major, just the a mention of cookie_jar and additional headers
>> via the second param in GET (and probably others?).
>>
>> While I was at it, I made sure all of the need* examples were all the
>> same; which meant removing \& and &. The bare versions seemed to be
>> the most prevelant.
>
>
> Thanks Chris, commited. But see below.
>
> Also in the future please try to post diffs against the root of the
> project so it's easier to apply those. Thanks.
I assume you mean http://svn.apache.org/repos/asf/httpd/test/trunk/, and
not just the root of Apache-Test correct?
>
>> Index: TestRequest.pm
>> + Apache::TestRequest::user_agent(reset =>,
>> + cookie_jar => {});
>
>
> Sorry, but what's that 'reset => ' thing? I've committed just:
>
> Apache::TestRequest::user_agent(cookie_jar => {});
>
> as in the test.
Geez. Apparently I'm in the clouds this week. Maybe I need to do these
changes during the day instead of at night. :-/
>
>> =head1 FUNCTIONS
>>
>> C<Apache::TestRequest> exports a number of functions that will likely
>> @@ -837,6 +850,11 @@
>> Sends a simple GET request to the Apache test server. Returns an
>> C<HTTP::Response> object.
>>
>> +You can also supply additional headers to be sent with the request
>> +by adding their name/value pairs after the C<url> parameter:
>
>
> really it's a dup of the more extensive docs at:
> http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Well, yes, and that was on purpose. I hated reading the A-T pod and
never knowing there was an extra param for GET. THe pod usualy is enough
to get start, and I wouldn't exptec to have to read:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
Were you looking for something more extensive?
>
> but committed anyway :)
>
Re: [PATCH] Test & TestRequest pod
Posted by Stas Bekman <st...@stason.org>.
Christopher H. Laco wrote:
> OK, I'm a programmer, not a writer. Be gentle.
> Nothing major, just the a mention of cookie_jar and additional headers
> via the second param in GET (and probably others?).
>
> While I was at it, I made sure all of the need* examples were all the
> same; which meant removing \& and &. The bare versions seemed to be the
> most prevelant.
Thanks Chris, commited. But see below.
Also in the future please try to post diffs against the root of the
project so it's easier to apply those. Thanks.
> Index: TestRequest.pm
> + Apache::TestRequest::user_agent(reset =>,
> + cookie_jar => {});
Sorry, but what's that 'reset => ' thing? I've committed just:
Apache::TestRequest::user_agent(cookie_jar => {});
as in the test.
> =head1 FUNCTIONS
>
> C<Apache::TestRequest> exports a number of functions that will likely
> @@ -837,6 +850,11 @@
> Sends a simple GET request to the Apache test server. Returns an
> C<HTTP::Response> object.
>
> +You can also supply additional headers to be sent with the request
> +by adding their name/value pairs after the C<url> parameter:
really it's a dup of the more extensive docs at:
http://perl.apache.org/docs/general/testing/testing.html#Request_and_Response_Methods
but committed anyway :)
--
__________________________________________________________________
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