You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Torsten Foertsch <to...@gmx.net> on 2005/05/01 15:41:36 UTC
[PATCH]Re: Apache::Test question
Hi,
this is quite an old thread. But now I have found why it was not working.
On Sunday 19 December 2004 23:34, Stas Bekman wrote:
> Torsten Foertsch wrote:
> > On Thursday 16 December 2004 17:28, Stas Bekman wrote:
[...]
> right, but the idea was to grep and jump to the code following it, which
> brings us back to refresh().
>
> > While Apache::TestRunPerl::refresh is defined as:
> >
> > #if Apache::TestRun refreshes config in the middle of configure
> > #we need to re-add modperl configure hooks
> > sub refresh {
> > my $self = shift;
> > $self->SUPER::refresh;
> > $self->configure_modperl;
> > }
> >
> > and Apache::TestRun::refresh as:
> >
> > #throw away cached config and start fresh
> > sub refresh {
> > my $self = shift;
> > $self->opt_clean(1);
> > $self->{conf_opts}->{save} = delete $self->{conf_opts}->{thaw} || 1;
> > $self->{test_config} = $self->new_test_config()->httpd_config;
> > $self->{test_config}->{server}->{run} = $self;
> > $self->{server} = $self->{test_config}->server;
> > }
> >
> > At least the comments lead to the idea that refresh() is actually what I
> > want.
>
> right, so see why the cache file is not updated? I think it's because it's
> not saved and you still use the old config object.
>
> Just so that you don't get mislead, Torsten, I'm not trying to figure out
> what the problem is (at least not yet), hoping that you will. Since as far
> as public API goes, everything works and refresh() is not a public API (at
> least not yet). I was just trying to point you to where the solution might
> be.
Let's start with a short explanation what I was trying to do. I wanted to test
a module with mod_ssl loaded in the first run and without it in the second
one. Hence my TEST.PL looks:
-----------------------------------------
use strict;
use warnings FATAL => 'all';
use lib qw(lib);
use Apache::TestRunPerl ();
my $I=Apache::TestRunPerl->new;
my @argv=@ARGV; # save
$I->run(@ARGV);
@ARGV=@argv; # restore
Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
$I->refresh;
$I->run(@ARGV);
-----------------------------------------
Both test runs work fine if put each in a separate TEST.PL. But I want them in
the same TEST.PL. To recreate the t/conf/httpd.conf between the runs
refresh() is called. Before the second run mod_ssl is skipped from the
configuration.
Now I also have to check whether mod_ssl is loaded from within my tests. I
tried to use need_module() for that.
What happens?
t/conf/httpd.conf is correctly recreated between the runs but need_module()
does not reflect the skipped module.
need_module() works on $cfg->{modules}. Hence this array must not contain
mod_ssl.
How is the configuration built?
I thought that calling t/TEST first inherits the configuration from an
existing httpd.conf and stores it into t/conf/apache_test_config.pm.
Subsequent calls from the actual tests the restore and use the cached
configuration.
But this was wrong particularly for the module list.
Apache::TestConfig::Parse::inherit_load_module() fetches the module list from
an existing httpd.conf. It is called once from t/TEST to generate
t/conf/httpd.conf and once for each test that uses the configuration. For
each test the inherited configuration is the merged with the cached one.
Hence, even if the cached configuration would reflect a skipped module the
one actually used by need_module would not anymore.
To avoid this problem I have introduced a new config attribute "thawed" that
is set in Apache::TestConfig::thaw. If it is set
Apache::TestConfig::Parse::inherit_load_module will immediately return
leaving the cached module list intact. That is not a satisfying solution
because there should be no need to inherit from a httpd.conf for each test.
The cached config should provide any information needed.
But a skipped module is not reflected even in the cached configuration. The
reason is the order of the should_kip_module-test and the inclusion in the
module list (also Apache::TestConfigParse::inherit_load_module). The patch
reverses that order.
The patch is against Apache::Test 1.22 that comes with RC5. All RC5 tests pass
with the patch applied.
I think it is worth to have an interface to do this kind of testing. Or is
there another way to get a module tested both with and without a particular
module loaded?
Of course there is still necessary a check for the compiled-in case.
Torsten
Re: [PATCH]Re: Apache::Test question
Posted by Stas Bekman <st...@stason.org>.
Torsten Foertsch wrote:
[...]
>>>Let's start with a short explanation what I was trying to do. I wanted to
>>>test a module with mod_ssl loaded in the first run and without it in the
>>>second one. Hence my TEST.PL looks:
>>>
>>>-----------------------------------------
>>>use strict;
>>>use warnings FATAL => 'all';
>>>
>>>use lib qw(lib);
>>>
>>>use Apache::TestRunPerl ();
>>>
>>>my $I=Apache::TestRunPerl->new;
>>>
>>>my @argv=@ARGV; # save
>>>$I->run(@ARGV);
>>>
>>>@ARGV=@argv; # restore
>>>Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
>>>
>>>$I->refresh;
>>>
>>>$I->run(@ARGV);
>>>-----------------------------------------
>>>
>>>Both test runs work fine if put each in a separate TEST.PL. But I want
>>>them in the same TEST.PL. To recreate the t/conf/httpd.conf between the
>>>runs refresh() is called. Before the second run mod_ssl is skipped from
>>>the configuration.
>>>
>>>Now I also have to check whether mod_ssl is loaded from within my tests.
>>>I tried to use need_module() for that.
>>>
>>>What happens?
>>>
>>>t/conf/httpd.conf is correctly recreated between the runs but
>>>need_module() does not reflect the skipped module.
>>>
>>>need_module() works on $cfg->{modules}. Hence this array must not contain
>>>mod_ssl.
>>>
>>>How is the configuration built?
>>>
>>>I thought that calling t/TEST first inherits the configuration from an
>>>existing httpd.conf and stores it into t/conf/apache_test_config.pm.
>>>Subsequent calls from the actual tests the restore and use the cached
>>>configuration.
>>>
>>>But this was wrong particularly for the module list.
>>>
>>>Apache::TestConfig::Parse::inherit_load_module() fetches the module list
>>>from an existing httpd.conf. It is called once from t/TEST to generate
>>>t/conf/httpd.conf and once for each test that uses the configuration. For
>>>each test the inherited configuration is the merged with the cached one.
>>>Hence, even if the cached configuration would reflect a skipped module
>>>the one actually used by need_module would not anymore.
>>>
>>>To avoid this problem I have introduced a new config attribute "thawed"
>>>that is set in Apache::TestConfig::thaw. If it is set
>>>Apache::TestConfig::Parse::inherit_load_module will immediately return
>>>leaving the cached module list intact. That is not a satisfying solution
>>>because there should be no need to inherit from a httpd.conf for each
>>>test. The cached config should provide any information needed.
>>>
>>>But a skipped module is not reflected even in the cached configuration.
>>>The reason is the order of the should_kip_module-test and the inclusion
>>>in the module list (also Apache::TestConfigParse::inherit_load_module).
>>>The patch reverses that order.
>>>
>>>The patch is against Apache::Test 1.22 that comes with RC5. All RC5 tests
>>>pass with the patch applied.
>>>
>>>I think it is worth to have an interface to do this kind of testing. Or
>>>is there another way to get a module tested both with and without a
>>>particular module loaded?
>>>
>>>Of course there is still necessary a check for the compiled-in case.
If it doesn't break existing test suites, I've no problem putting it in.
Mind to create a new patch for the latest version? Please observe the
coding guidelines (no tabs). Also please add a comment in the code of why
you return and document the refresh method giving an example on why and
how one may want to use it. Thanks Torsten.
>>>diff -Naur mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfigParse.pm mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfigParse.pm
>>>--- mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfigParse.pm 2005-04-14 14:20:29.000000000 +0200
>>>+++ mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfigParse.pm 2005-04-29 21:03:41.801355900 +0200
>>>@@ -190,6 +190,7 @@
>>> sub inherit_load_module {
>>> my($self, $c, $directive) = @_;
>>>
>>>+ return if( $self->{thawed} );
>>> for my $args (@{ $c->{$directive} }) {
>>> my $modname = $args->[0];
>>> my $file = $self->server_file_rel2abs($args->[1]);
>>>@@ -205,8 +206,6 @@
>>>
>>> $name = $modname_alias{$name} if $modname_alias{$name};
>>>
>>>- # remember all found modules
>>>- $self->{modules}->{$name} = $file;
>>> debug "Found: $modname => $name";
>>>
>>> if ($self->should_skip_module($name)) {
>>>@@ -214,6 +213,9 @@
>>> next;
>>> }
>>>
>>>+ # remember all found modules
>>>+ $self->{modules}->{$name} = $file;
>>>+
>>> debug "LoadModule $modname $name";
>>>
>>> # sometimes people have broken system-wide httpd.conf files,
>>>diff -Naur mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfig.pm mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfig.pm
>>>--- mod_perl-2.0.0-RC5/Apache-Test/lib/Apache/TestConfig.pm 2005-04-14 14:20:26.000000000 +0200
>>>+++ mod_perl-2.0.0-RC5.new/Apache-Test/lib/Apache/TestConfig.pm 2005-04-29 20:58:01.272674035 +0200
>>>@@ -226,6 +226,7 @@
>>> require "$_/apache_test_config.pm";
>>> $thaw = 'apache_test_config'->new;
>>> delete $thaw->{save};
>>>+ $thaw->{thawed}=1;
>>> #incase class that generated the config was
>>> #something else, which we can't be sure how to load
>>> bless $thaw, 'Apache::TestConfig';
--
__________________________________________________________________
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
[PATCH]Re: Apache::Test question
Posted by Torsten Foertsch <to...@gmx.net>.
On Tuesday 17 May 2005 20:55, Stas Bekman wrote:
> Torsten Foertsch wrote:
> > Hi,
> >
> > this is quite an old thread. But now I have found why it was not working.
>
> Torsten, could you please repost it to the test-dev@perl.apache.org list.
> We will take it from there.
>
> Thanks.
here it is.
>
> > On Sunday 19 December 2004 23:34, Stas Bekman wrote:
> >>Torsten Foertsch wrote:
> >>>On Thursday 16 December 2004 17:28, Stas Bekman wrote:
> >
> > [...]
> >
> >>right, but the idea was to grep and jump to the code following it, which
> >>brings us back to refresh().
> >>
> >>>While Apache::TestRunPerl::refresh is defined as:
> >>>
> >>>#if Apache::TestRun refreshes config in the middle of configure
> >>>#we need to re-add modperl configure hooks
> >>>sub refresh {
> >>> my $self = shift;
> >>> $self->SUPER::refresh;
> >>> $self->configure_modperl;
> >>>}
> >>>
> >>>and Apache::TestRun::refresh as:
> >>>
> >>>#throw away cached config and start fresh
> >>>sub refresh {
> >>> my $self = shift;
> >>> $self->opt_clean(1);
> >>> $self->{conf_opts}->{save} = delete $self->{conf_opts}->{thaw} || 1;
> >>> $self->{test_config} = $self->new_test_config()->httpd_config;
> >>> $self->{test_config}->{server}->{run} = $self;
> >>> $self->{server} = $self->{test_config}->server;
> >>>}
> >>>
> >>>At least the comments lead to the idea that refresh() is actually what I
> >>>want.
> >>
> >>right, so see why the cache file is not updated? I think it's because
> >> it's not saved and you still use the old config object.
> >>
> >>Just so that you don't get mislead, Torsten, I'm not trying to figure out
> >>what the problem is (at least not yet), hoping that you will. Since as
> >> far as public API goes, everything works and refresh() is not a public
> >> API (at least not yet). I was just trying to point you to where the
> >> solution might be.
> >
> > Let's start with a short explanation what I was trying to do. I wanted to
> > test a module with mod_ssl loaded in the first run and without it in the
> > second one. Hence my TEST.PL looks:
> >
> > -----------------------------------------
> > use strict;
> > use warnings FATAL => 'all';
> >
> > use lib qw(lib);
> >
> > use Apache::TestRunPerl ();
> >
> > my $I=Apache::TestRunPerl->new;
> >
> > my @argv=@ARGV; # save
> > $I->run(@ARGV);
> >
> > @ARGV=@argv; # restore
> > Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
> >
> > $I->refresh;
> >
> > $I->run(@ARGV);
> > -----------------------------------------
> >
> > Both test runs work fine if put each in a separate TEST.PL. But I want
> > them in the same TEST.PL. To recreate the t/conf/httpd.conf between the
> > runs refresh() is called. Before the second run mod_ssl is skipped from
> > the configuration.
> >
> > Now I also have to check whether mod_ssl is loaded from within my tests.
> > I tried to use need_module() for that.
> >
> > What happens?
> >
> > t/conf/httpd.conf is correctly recreated between the runs but
> > need_module() does not reflect the skipped module.
> >
> > need_module() works on $cfg->{modules}. Hence this array must not contain
> > mod_ssl.
> >
> > How is the configuration built?
> >
> > I thought that calling t/TEST first inherits the configuration from an
> > existing httpd.conf and stores it into t/conf/apache_test_config.pm.
> > Subsequent calls from the actual tests the restore and use the cached
> > configuration.
> >
> > But this was wrong particularly for the module list.
> >
> > Apache::TestConfig::Parse::inherit_load_module() fetches the module list
> > from an existing httpd.conf. It is called once from t/TEST to generate
> > t/conf/httpd.conf and once for each test that uses the configuration. For
> > each test the inherited configuration is the merged with the cached one.
> > Hence, even if the cached configuration would reflect a skipped module
> > the one actually used by need_module would not anymore.
> >
> > To avoid this problem I have introduced a new config attribute "thawed"
> > that is set in Apache::TestConfig::thaw. If it is set
> > Apache::TestConfig::Parse::inherit_load_module will immediately return
> > leaving the cached module list intact. That is not a satisfying solution
> > because there should be no need to inherit from a httpd.conf for each
> > test. The cached config should provide any information needed.
> >
> > But a skipped module is not reflected even in the cached configuration.
> > The reason is the order of the should_kip_module-test and the inclusion
> > in the module list (also Apache::TestConfigParse::inherit_load_module).
> > The patch reverses that order.
> >
> > The patch is against Apache::Test 1.22 that comes with RC5. All RC5 tests
> > pass with the patch applied.
> >
> > I think it is worth to have an interface to do this kind of testing. Or
> > is there another way to get a module tested both with and without a
> > particular module loaded?
> >
> > Of course there is still necessary a check for the compiled-in case.
> >
> > Torsten