You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/04/17 21:48:33 UTC
[mp2] starting new test category
It looks like besides testing the API we also may want to test some common
techniques. e.g. for one of the recent problem reports on the modperl list, I
wrote this rewrite test. Should I commit it? If so, should we start a new
category of tests for common techniques. Not sure what's the best short name,
'cooks', 'recetas' or 'fill in some short name'?
BTW, Apache now requires you to set $r->filename() if you return Apache::OK
from the transhandler. In this test I simply left for Apache to figure it out,
but obviously we get the stat() calls perfomance hit. So it's probably better to:
sub trans {
my $r = shift;
$r->uri($uri_real);
$r->args($args_real);
$r->filename(''); # make Apache happy
return Apache::OK;
}
and return OK.
Anyway, here is a simple test.
package TestModules::rewrite;
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::URI ();
use Apache::Const -compile => qw(DECLINED OK);
my $uri_real = "/TestModules__rewrite_real";
my $args_real = "foo=bar&boo=tar";
sub trans {
my $r = shift;
return Apache::DECLINED unless $r->uri eq '/TestModules__rewrite';
$r->uri($uri_real);
$r->args($args_real);
return Apache::DECLINED;
}
sub response {
my $r = shift;
plan $r, tests => 1;
my $args = $r->args();
ok t_cmp($args_real, $args, "args");
return Apache::OK;
}
1;
__END__
<NoAutoConfig>
PerlModule TestModules::rewrite
PerlTransHandler TestModules::rewrite::trans
<Location /TestModules__rewrite_real>
SetHandler modperl
PerlResponseHandler TestModules::rewrite::response
</Location>
</NoAutoConfig>
--
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] starting new test category
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>what about just 'user'?
>>
>>
>>and what's the mnemonic here? Really, this could be anything,
>
>
> yes, I think that was my point. 'user' would be userspace tests, such as
> those that excercise non-unit, multiple-API tests, or apache integration
> tests, etc. you were asking for suggestions, and it's much more intuitive
> to me than 'cooks' :)
Sure, I'm not against your suggestion, I was just asking for the
logic/mnemonics for the suggested name, which is exactly what you gave above.
It makes sense to me. So let's do that.
>>>good thing we have a PerlMapToStorageHandler ;)
>>
>>
>>Yeah, good indeed.
>>
>>First of all, how about dumping the above into
>>modperl-docs/src/docs/2.0/user/handlers/http.pod? That new phase is
>>completely undocumented (besides mentioning that it exists). And
>>mentioning in the performance chapter that one needs to use
>>PerlMapToStorageHandler to shortcut the stat() calls.
>
>
> I'll try to come up with something soonish.
Thanks!
[I agree with the rest and hoping that this discussion will end up in the docs
:) ]
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] starting new test category
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> what about just 'user'?
>
>
> and what's the mnemonic here? Really, this could be anything,
yes, I think that was my point. 'user' would be userspace tests, such as
those that excercise non-unit, multiple-API tests, or apache integration
tests, etc. you were asking for suggestions, and it's much more intuitive
to me than 'cooks' :)
>> good thing we have a PerlMapToStorageHandler ;)
>
>
> Yeah, good indeed.
>
> First of all, how about dumping the above into
> modperl-docs/src/docs/2.0/user/handlers/http.pod? That new phase is
> completely undocumented (besides mentioning that it exists). And
> mentioning in the performance chapter that one needs to use
> PerlMapToStorageHandler to shortcut the stat() calls.
I'll try to come up with something soonish.
> I guess with:
>
> PerlMapToStorageHandler Apache::OK
>
> which will work only if all requests are to the virtual namespace.
yes, and the same was true in the mp1/PerlTransHandler case.
> I've
> changed the test below to do it only for that particular test.
cool.
>
> Still it's possible that
>
> $r->filename('');
>
> in transhandler (if you do rewrite the namespace already) is another
> working solution too, since you need the transhandler, and you don't
> need to write a maptostorage handler at all.
it looks like core_map_to_storage will be short-circuited in that case, but
with a different warning (unless the '' gets translated to NULL someplace).
nevertheless, that's a bit hackish. the new idiom is to use the
PerlTransHandler to translate the URI to a filename, and the
PerlMapToStorageHandler to map the filename to a physical file on disk. so,
in examples, tests, and whatnot I'd try to emphasize the difference and use
only the appropriate hook so it will help people learn. what we do in our
own code is another matter :)
> You suggest to skip the PerlTransHandler completely only when you want
> to avoid the stat calls, right?
yes, I think that's the right thing to do.
> You still need it for rewrites.
indeed. I was commenting in a 'knowledge for knowledge sake' sense, not
necessarily to say you didn't need the trans handler in your test.
however, in your new test...
> #$r->filename(''); # make Apache happy
this is not required since you
> # skip ap_directory_walk stat() calls
HTH
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] starting new test category
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>It looks like besides testing the API we also may want to test some
>>common techniques. e.g. for one of the recent problem reports on the
>>modperl list, I wrote this rewrite test. Should I commit it? If so,
>>should we start a new category of tests for common techniques. Not sure
>>what's the best short name, 'cooks', 'recetas' or 'fill in some short
>>name'?
>
>
> what about just 'user'?
and what's the mnemonic here? Really, this could be anything, I'm just trying
to come up with the name that when next time we need to add a new test we
don't need to thinking for too long to figure out which group to add it to.
In any case, shell we add that test?
>>BTW, Apache now requires you to set $r->filename() if you return
>>Apache::OK from the transhandler.
>
>
> well, that's true but I think your comment is a bit misleading.
>
> returning OK from a trans handler _means_ that you have set r->filename. in
> other words, Apache is both expecting and enforcing that r->filename be set
> by the end of translation. but wait, there's more...
Yes, but it wasn't so in mp1. In mp1 you return OK without setting r->filename
and Apache has no problem with that. Hence was my comment.
>>In this test I simply left for Apache
>>to figure it out, but obviously we get the stat() calls perfomance hit.
>
>
> the old reason that we used to return OK from a trans handler was to avoid
> the stat for non-file URIs. however, this stat now happens in
> map-to-storage, not translation. hence it is core_map_to_storage that
> throws the "module bug?" warning. well, ok, it's ap_directory_walk, but now
> that is only called from core_map_to_storage (and a few other modules like
> proxy and dav).
>
> so, what this means is that if you want to avoid the stat call you need to
> return OK from a PerlMapToStorageHandler, not the PerlTransHandler. also,
> in these cases you can skip the PerlTransHandler altogether - there is no
> benefit whatsoever from returning OK from perl except that it might actually
> slow you down, depending on how fast the perl is compared to ap_core_translate.
>
> good thing we have a PerlMapToStorageHandler ;)
Yeah, good indeed.
First of all, how about dumping the above into
modperl-docs/src/docs/2.0/user/handlers/http.pod? That new phase is completely
undocumented (besides mentioning that it exists). And mentioning in the
performance chapter that one needs to use PerlMapToStorageHandler to shortcut
the stat() calls. I guess with:
PerlMapToStorageHandler Apache::OK
which will work only if all requests are to the virtual namespace. I've
changed the test below to do it only for that particular test.
Still it's possible that
$r->filename('');
in transhandler (if you do rewrite the namespace already) is another working
solution too, since you need the transhandler, and you don't need to write a
maptostorage handler at all.
You suggest to skip the PerlTransHandler completely only when you want to
avoid the stat calls, right? You still need it for rewrites.
package TestModules::rewrite;
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::URI ();
use Apache::Const -compile => qw(DECLINED OK);
my $uri_real = "/TestModules__rewrite_real";
my $args_real = "foo=bar&boo=tar";
sub trans {
my $r = shift;
return Apache::DECLINED unless $r->uri eq '/TestModules__rewrite';
$r->uri($uri_real);
$r->args($args_real);
#$r->filename(''); # make Apache happy
return Apache::OK;
}
sub map2storage {
my $r = shift;
return Apache::DECLINED unless $r->uri eq $uri_real;
# skip ap_directory_walk stat() calls
return Apache::OK;
}
sub response {
my $r = shift;
plan $r, tests => 1;
my $args = $r->args();
ok t_cmp($args_real, $args, "args");
return Apache::OK;
}
1;
__END__
<NoAutoConfig>
PerlModule TestModules::rewrite
PerlTransHandler TestModules::rewrite::trans
PerlMapToStorageHandler TestModules::rewrite::map2storage
<Location /TestModules__rewrite_real>
SetHandler modperl
PerlResponseHandler TestModules::rewrite::response
</Location>
</NoAutoConfig>
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] starting new test category
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> It looks like besides testing the API we also may want to test some
> common techniques. e.g. for one of the recent problem reports on the
> modperl list, I wrote this rewrite test. Should I commit it? If so,
> should we start a new category of tests for common techniques. Not sure
> what's the best short name, 'cooks', 'recetas' or 'fill in some short
> name'?
what about just 'user'?
>
> BTW, Apache now requires you to set $r->filename() if you return
> Apache::OK from the transhandler.
well, that's true but I think your comment is a bit misleading.
returning OK from a trans handler _means_ that you have set r->filename. in
other words, Apache is both expecting and enforcing that r->filename be set
by the end of translation. but wait, there's more...
> In this test I simply left for Apache
> to figure it out, but obviously we get the stat() calls perfomance hit.
the old reason that we used to return OK from a trans handler was to avoid
the stat for non-file URIs. however, this stat now happens in
map-to-storage, not translation. hence it is core_map_to_storage that
throws the "module bug?" warning. well, ok, it's ap_directory_walk, but now
that is only called from core_map_to_storage (and a few other modules like
proxy and dav).
so, what this means is that if you want to avoid the stat call you need to
return OK from a PerlMapToStorageHandler, not the PerlTransHandler. also,
in these cases you can skip the PerlTransHandler altogether - there is no
benefit whatsoever from returning OK from perl except that it might actually
slow you down, depending on how fast the perl is compared to ap_core_translate.
good thing we have a PerlMapToStorageHandler ;)
HTH
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org