Loading ...
Sorry, an error occurred while loading the content.

Apache::Test question

Expand Messages
  • Torsten Foertsch
    Hi, I want my test suite run once with mod_ssl.so loaded and once without. My TEST.PL looks this: use strict; use warnings FATAL = all ; use lib qw(lib); use
    Message 1 of 14 , Dec 15, 2004
    • 0 Attachment
      Hi,

      I want my test suite run once with mod_ssl.so loaded and once without. My
      TEST.PL looks this:

      use strict;
      use warnings FATAL => 'all';

      use lib qw(lib);

      use Apache::TestRunPerl ();

      my $I=Apache::TestRunPerl->new;

      $I->run(@ARGV);

      Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');

      $I->refresh;

      $I->run(@ARGV);

      This works fine but I need to know in my handlers and in the tests itself what
      case is running. For the handlers I set a variable in extra.conf.in:

      <IfModule mod_ssl.c>
      PerlSetVar HAVE_SSL 1
      </IfModule>

      But how do I know it in the tests? Is there another way except of scanning
      conf/httpd.conf?

      Torsten
    • Stas Bekman
      ... you probably want to copy @ARGV away and pass a copy, since run() mangles it. ... You do: use Apache::Test; plan tests = 5, need_module ssl ; It s
      Message 2 of 14 , Dec 15, 2004
      • 0 Attachment
        Torsten Foertsch wrote:
        > Hi,
        >
        > I want my test suite run once with mod_ssl.so loaded and once without. My
        > TEST.PL looks this:
        >
        > use strict;
        > use warnings FATAL => 'all';
        >
        > use lib qw(lib);
        >
        > use Apache::TestRunPerl ();
        >
        > my $I=Apache::TestRunPerl->new;
        >
        > $I->run(@ARGV);
        >
        > Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
        >
        > $I->refresh;
        >
        > $I->run(@ARGV);

        you probably want to copy @ARGV away and pass a copy, since run() mangles it.

        > This works fine but I need to know in my handlers and in the tests itself what
        > case is running. For the handlers I set a variable in extra.conf.in:
        >
        > <IfModule mod_ssl.c>
        > PerlSetVar HAVE_SSL 1
        > </IfModule>
        >
        > But how do I know it in the tests? Is there another way except of scanning
        > conf/httpd.conf?

        You do:

        use Apache::Test;
        plan tests => 5, need_module 'ssl';

        It's documented in the Apache::Test manpage and also here:
        http://perl.apache.org/docs/general/testing/testing.html
        feel free to suggest an improvement if you couldn't find that information
        when you read those docs. (you did read those, right? :)

        BTW, I don't think we have this technique documented anywhere, if you
        could submit it as a patch to testing.pod that would be a great addition.

        --
        __________________________________________________________________
        Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
        http://stason.org/ mod_perl Guide ---> http://perl.apache.org
        mailto:stas@... http://use.perl.org http://apacheweek.com
        http://modperlbook.org http://apache.org http://ticketmaster.com

        --
        Report problems: http://perl.apache.org/bugs/
        Mail list info: http://perl.apache.org/maillist/modperl.html
        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
      • Torsten Foertsch
        ... yes, I did. I am aware of need_module() and have_module() being almost the same thing. Now please have a look at Apache::ModSSL/t/1is_https.t and TEST.PL:
        Message 3 of 14 , Dec 16, 2004
        • 0 Attachment
          On Wednesday 15 December 2004 20:46, Stas Bekman wrote:
          > Torsten Foertsch wrote:
          > > But how do I know it in the tests? Is there another way except of
          > > scanning conf/httpd.conf?
          >
          > You do:
          >
          > use Apache::Test;
          > plan tests => 5, need_module 'ssl';
          >
          > It's documented in the Apache::Test manpage and also here:
          > http://perl.apache.org/docs/general/testing/testing.html
          > feel free to suggest an improvement if you couldn't find that information
          > when you read those docs. (you did read those, right? :)

          yes, I did. I am aware of need_module() and have_module() being almost
          the same thing. Now please have a look at Apache::ModSSL/t/1is_https.t
          and TEST.PL:

          TEST.PL:
          -----------------------------------------------------------------------------------------------
          ...
          my $I=Apache::TestRunPerl->new;

          my @argv=@ARGV; # save it

          $I->run(@ARGV);
          system "cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm1";

          Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');

          $I->refresh;

          $I->run(@argv);
          system "cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm2";
          -----------------------------------------------------------------------------------------------

          For debugging I am duplicating the generated apache_test_config.pm files.
          They do differ. The 2nd one lacks the "LoadModule ssl_module" as expected.

          ...
          @@ -308,10 +308,6 @@
          LoadModule rewrite_module "/usr/lib/apache2-prefork/mod_rewrite.so"
          </IfModule>
          ',
          - '<IfModule !mod_ssl.c>
          - LoadModule ssl_module "/usr/lib/apache2-prefork/mod_ssl.so"
          -</IfModule>
          -',
          '<IfModule !mod_unique_id.c>
          LoadModule unique_id_module "/usr/lib/apache2-prefork/mod_unique_id.so"
          </IfModule>
          ...

          1is_https.t:
          -----------------------------------------------------------------------------------------------
          ...
          sub ssl_loaded {
          open my $f, "t/conf/httpd.conf" or die "ERROR: Cannot read t/conf/httpd.conf: $!";
          return grep(/^\s*LoadModule\s+ssl_module\b/, <$f>) ? 1 : 0;
          }
          ...
          #if( have_module('ssl') ) {
          if( ssl_loaded ) {
          plan tests => 2;

          ok t_cmp( test( 'default', 'is_https' ), "HAVE_SSL=1 is_https: 0\n", "no ssl" );
          ok t_cmp( test( 'SSL', 'is_https' ), "HAVE_SSL=1 is_https: 1\n", "ssl" );
          } else {
          plan tests => 1;

          ok t_cmp( test( 'default', 'is_https' ), "HAVE_SSL= is_https: UNDEF\n", "no ssl" );
          }
          -----------------------------------------------------------------------------------------------

          My ssl_loaded() function distinguishes between the 2 cases, have_module('ssl')
          does not. With have_module() always the 1st case is entered.

          Here is an excerpt of Apache::Test:

          sub need_module {
          ...
          for (@modules) {
          ...
          next if $cfg->{modules}->{$mod};
          if (exists $cfg->{cmodules_disabled}->{$mod}) {
          push @reasons, $cfg->{cmodules_disabled}->{$mod};
          next;
          }
          ...
          }
          ...
          }

          Since my Apache::TestConfig in both cases contains "mod_ssl.c" in
          $cfg->{modules} the test will succeed. The
          "Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');"
          is disregarded while generating this hash.

          Torsten
        • Stas Bekman
          ... Right, because as you ve figured out t/conf/apache_test_config.pm is a cached version of the the test setup data. So you need to do a cleanup before
          Message 4 of 14 , Dec 16, 2004
          • 0 Attachment
            Torsten Foertsch wrote:
            > On Wednesday 15 December 2004 20:46, Stas Bekman wrote:
            >
            >>Torsten Foertsch wrote:
            >>
            >>>But how do I know it in the tests? Is there another way except of
            >>>scanning conf/httpd.conf?
            >>
            >>You do:
            >>
            >>use Apache::Test;
            >>plan tests => 5, need_module 'ssl';
            >>
            >>It's documented in the Apache::Test manpage and also here:
            >>http://perl.apache.org/docs/general/testing/testing.html
            >>feel free to suggest an improvement if you couldn't find that information
            >>when you read those docs. (you did read those, right? :)
            >
            >
            > yes, I did. I am aware of need_module() and have_module() being almost
            > the same thing. Now please have a look at Apache::ModSSL/t/1is_https.t
            > and TEST.PL:
            >
            > TEST.PL:
            > -----------------------------------------------------------------------------------------------
            > ...
            > my $I=Apache::TestRunPerl->new;
            >
            > my @argv=@ARGV; # save it
            >
            > $I->run(@ARGV);
            > system "cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm1";
            >
            > Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');
            >
            > $I->refresh;
            >
            > $I->run(@argv);
            > system "cp t/conf/apache_test_config.pm t/conf/apache_test_config.pm2";
            > -----------------------------------------------------------------------------------------------
            >
            > For debugging I am duplicating the generated apache_test_config.pm files.
            > They do differ. The 2nd one lacks the "LoadModule ssl_module" as expected.
            >
            > ...
            > @@ -308,10 +308,6 @@
            > LoadModule rewrite_module "/usr/lib/apache2-prefork/mod_rewrite.so"
            > </IfModule>
            > ',
            > - '<IfModule !mod_ssl.c>
            > - LoadModule ssl_module "/usr/lib/apache2-prefork/mod_ssl.so"
            > -</IfModule>
            > -',
            > '<IfModule !mod_unique_id.c>
            > LoadModule unique_id_module "/usr/lib/apache2-prefork/mod_unique_id.so"
            > </IfModule>
            > ...
            >
            > 1is_https.t:
            > -----------------------------------------------------------------------------------------------
            > ...
            > sub ssl_loaded {
            > open my $f, "t/conf/httpd.conf" or die "ERROR: Cannot read t/conf/httpd.conf: $!";
            > return grep(/^\s*LoadModule\s+ssl_module\b/, <$f>) ? 1 : 0;
            > }
            > ...
            > #if( have_module('ssl') ) {
            > if( ssl_loaded ) {
            > plan tests => 2;
            >
            > ok t_cmp( test( 'default', 'is_https' ), "HAVE_SSL=1 is_https: 0\n", "no ssl" );
            > ok t_cmp( test( 'SSL', 'is_https' ), "HAVE_SSL=1 is_https: 1\n", "ssl" );
            > } else {
            > plan tests => 1;
            >
            > ok t_cmp( test( 'default', 'is_https' ), "HAVE_SSL= is_https: UNDEF\n", "no ssl" );
            > }
            > -----------------------------------------------------------------------------------------------
            >
            > My ssl_loaded() function distinguishes between the 2 cases, have_module('ssl')
            > does not. With have_module() always the 1st case is entered.
            >
            > Here is an excerpt of Apache::Test:
            >
            > sub need_module {
            > ...
            > for (@modules) {
            > ...
            > next if $cfg->{modules}->{$mod};
            > if (exists $cfg->{cmodules_disabled}->{$mod}) {
            > push @reasons, $cfg->{cmodules_disabled}->{$mod};
            > next;
            > }
            > ...
            > }
            > ...
            > }
            >
            > Since my Apache::TestConfig in both cases contains "mod_ssl.c" in
            > $cfg->{modules} the test will succeed. The
            > "Apache::TestConfig::autoconfig_skip_module_add('mod_ssl.c');"
            > is disregarded while generating this hash.

            Right, because as you've figured out t/conf/apache_test_config.pm is a
            cached version of the the test setup data. So you need to do a cleanup
            before reconfiguring things so that file gets updated. Note that you
            perform things A-T has no top-level support for at the moment. Since your
            hack uses internal APIs it can break any moment if things change. So it's
            important to provide a public API for this kind of purposes.

            grep the source for reconfigure() which I think will enforce the re-cache.


            --
            __________________________________________________________________
            Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
            http://stason.org/ mod_perl Guide ---> http://perl.apache.org
            mailto:stas@... http://use.perl.org http://apacheweek.com
            http://modperlbook.org http://apache.org http://ticketmaster.com

            --
            Report problems: http://perl.apache.org/bugs/
            Mail list info: http://perl.apache.org/maillist/modperl.html
            List etiquette: http://perl.apache.org/maillist/email-etiquette.html
          • William McKee
            ... Hi Torsten, This is an interesting approach you are using. I have opted for creating a virtual server in my extra.conf.in config file called ssl which
            Message 5 of 14 , Dec 16, 2004
            • 0 Attachment
              On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote:
              > Right, because as you've figured out t/conf/apache_test_config.pm is a
              > cached version of the the test setup data. So you need to do a cleanup
              > before reconfiguring things so that file gets updated. Note that you
              > perform things A-T has no top-level support for at the moment. Since your
              > hack uses internal APIs it can break any moment if things change. So it's
              > important to provide a public API for this kind of purposes.

              Hi Torsten,

              This is an interesting approach you are using. I have opted for creating
              a virtual server in my extra.conf.in config file called 'ssl' which
              turns on mod_ssl in order to do my tests which require an ssl
              connection. When I want to use the SSL connection in a request test, I
              do the following:

              my $config = Apache::Test::config();
              Apache::TestRequest::module('ssl');
              my $hostport = Apache::TestRequest::hostport();

              I suppose this would not work for the automatically built response tests
              which use the default port.


              William

              --
              Knowmad Services Inc.
              http://www.knowmad.com

              --
              Report problems: http://perl.apache.org/bugs/
              Mail list info: http://perl.apache.org/maillist/modperl.html
              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
            • Stas Bekman
              William McKee wrote: [...] ... BTW, A-T 1.17 has a new shortcut which does all the above: $url = Apache::TestRequest::module2url( ssl ); ... right, but you
              Message 6 of 14 , Dec 16, 2004
              • 0 Attachment
                William McKee wrote:
                [...]

                > When I want to use the SSL connection in a request test, I
                > do the following:
                >
                > my $config = Apache::Test::config();
                > Apache::TestRequest::module('ssl');
                > my $hostport = Apache::TestRequest::hostport();

                BTW, A-T 1.17 has a new shortcut which does all the above:

                $url = Apache::TestRequest::module2url('ssl');

                > I suppose this would not work for the automatically built response tests
                > which use the default port.

                right, but you can't really run SSL tests with a manually coded client,
                can you?





                --
                __________________________________________________________________
                Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                mailto:stas@... http://use.perl.org http://apacheweek.com
                http://modperlbook.org http://apache.org http://ticketmaster.com

                --
                Report problems: http://perl.apache.org/bugs/
                Mail list info: http://perl.apache.org/maillist/modperl.html
                List etiquette: http://perl.apache.org/maillist/email-etiquette.html
              • Geoffrey Young
                ... cool. ... yes, you can. see the Live tests in Apache-SSLLookup. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info:
                Message 7 of 14 , Dec 16, 2004
                • 0 Attachment
                  Stas Bekman wrote:
                  > William McKee wrote:
                  > [...]
                  >
                  >> When I want to use the SSL connection in a request test, I
                  >> do the following:
                  >>
                  >> my $config = Apache::Test::config();
                  >> Apache::TestRequest::module('ssl');
                  >> my $hostport = Apache::TestRequest::hostport();
                  >
                  >
                  > BTW, A-T 1.17 has a new shortcut which does all the above:
                  >
                  > $url = Apache::TestRequest::module2url('ssl');

                  cool.

                  >
                  >> I suppose this would not work for the automatically built response tests
                  >> which use the default port.
                  >
                  >
                  > right, but you can't really run SSL tests with a manually coded client,
                  > can you?

                  yes, you can. see the "Live" tests in Apache-SSLLookup.

                  --Geoff

                  --
                  Report problems: http://perl.apache.org/bugs/
                  Mail list info: http://perl.apache.org/maillist/modperl.html
                  List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                • Geoffrey Young
                  ... right. but keep in mind that s not the same thing - Torsten is testing an httpd both with and without mod_ssl _compiled_, which is very different than
                  Message 8 of 14 , Dec 16, 2004
                  • 0 Attachment
                    William McKee wrote:
                    > On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote:
                    >
                    >>Right, because as you've figured out t/conf/apache_test_config.pm is a
                    >>cached version of the the test setup data. So you need to do a cleanup
                    >>before reconfiguring things so that file gets updated. Note that you
                    >>perform things A-T has no top-level support for at the moment. Since your
                    >>hack uses internal APIs it can break any moment if things change. So it's
                    >>important to provide a public API for this kind of purposes.
                    >
                    >
                    > Hi Torsten,
                    >
                    > This is an interesting approach you are using. I have opted for creating
                    > a virtual server in my extra.conf.in config file called 'ssl' which
                    > turns on mod_ssl in order to do my tests which require an ssl
                    > connection.

                    right. but keep in mind that's not the same thing - Torsten is testing an
                    httpd both with and without mod_ssl _compiled_, which is very different than
                    requests with and without ssl _enabled_, especially when you need to code
                    internal logic around the presense of these optional functions.

                    of course, if you're using mod_ssl compiled in statically the approach won't
                    work, but it's admirable and required, allt he same.

                    --Geoff

                    --
                    Report problems: http://perl.apache.org/bugs/
                    Mail list info: http://perl.apache.org/maillist/modperl.html
                    List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                  • Stas Bekman
                    ... I m not sure what do you mean, I ve looked at http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/ and the client is there manually coded. --
                    Message 9 of 14 , Dec 16, 2004
                    • 0 Attachment
                      Geoffrey Young wrote:

                      >>>I suppose this would not work for the automatically built response tests
                      >>>which use the default port.
                      >>
                      >>
                      >>right, but you can't really run SSL tests with a manually coded client,
                      >>can you?
                      >
                      >
                      > yes, you can. see the "Live" tests in Apache-SSLLookup.

                      I'm not sure what do you mean, I've looked at
                      http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/
                      and the client is there manually coded.

                      --
                      __________________________________________________________________
                      Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                      http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                      mailto:stas@... http://use.perl.org http://apacheweek.com
                      http://modperlbook.org http://apache.org http://ticketmaster.com

                      --
                      Report problems: http://perl.apache.org/bugs/
                      Mail list info: http://perl.apache.org/maillist/modperl.html
                      List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                    • Geoffrey Young
                      ... ^^^^^^^^^^^^^^^ but yes, I see that you meant the opposite, and you re right - you can t use autogenerated clients with server-side ssl tests, at least not
                      Message 10 of 14 , Dec 16, 2004
                      • 0 Attachment
                        >>> right, but you can't really run SSL tests with a manually coded client,
                        ^^^^^^^^^^^^^^^^^^^^^
                        >>> can you?
                        >>
                        >>
                        >>
                        >> yes, you can. see the "Live" tests in Apache-SSLLookup.
                        >
                        >
                        > I'm not sure what do you mean, I've looked at
                        > http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/
                        > and the client is there manually coded.
                        ^^^^^^^^^^^^^^^

                        but yes, I see that you meant the opposite, and you're right - you can't use
                        autogenerated clients with server-side ssl tests, at least not that I was
                        able to see.

                        --Geoff


                        --
                        Report problems: http://perl.apache.org/bugs/
                        Mail list info: http://perl.apache.org/maillist/modperl.html
                        List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                      • Stas Bekman
                        ... Ah, oops, yes, I meant that :) I guess if your default server is somehow configured to run ssl, then it should work. remember that t/TEST has the -ssl
                        Message 11 of 14 , Dec 16, 2004
                        • 0 Attachment
                          Geoffrey Young wrote:
                          >>>>right, but you can't really run SSL tests with a manually coded client,
                          >
                          > ^^^^^^^^^^^^^^^^^^^^^
                          >
                          >>>>can you?
                          >>>
                          >>>
                          >>>
                          >>>yes, you can. see the "Live" tests in Apache-SSLLookup.
                          >>
                          >>
                          >>I'm not sure what do you mean, I've looked at
                          >>http://search.cpan.org/src/GEOFF/Apache-SSLLookup-2.00_02/t/live/
                          >>and the client is there manually coded.
                          >
                          > ^^^^^^^^^^^^^^^
                          >
                          > but yes, I see that you meant the opposite, and you're right - you can't use
                          > autogenerated clients with server-side ssl tests, at least not that I was
                          > able to see.

                          Ah, oops, yes, I meant that :) I guess if your default server is somehow
                          configured to run ssl, then it should work. remember that t/TEST has the
                          -ssl option (I've never used it).

                          --
                          __________________________________________________________________
                          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                          mailto:stas@... http://use.perl.org http://apacheweek.com
                          http://modperlbook.org http://apache.org http://ticketmaster.com

                          --
                          Report problems: http://perl.apache.org/bugs/
                          Mail list info: http://perl.apache.org/maillist/modperl.html
                          List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                        • Torsten Foertsch
                          ... Sorry, I could not find it. Simply changing refresh to reconfigure yields: Can t locate object method reconfigure via package Apache::TestRunPerl at
                          Message 12 of 14 , Dec 19, 2004
                          • 0 Attachment
                            On Thursday 16 December 2004 17:28, Stas Bekman wrote:
                            > grep the source for reconfigure() which I think will enforce the re-cache.

                            Sorry, I could not find it. Simply changing refresh to reconfigure yields:

                            Can't locate object method "reconfigure" via package "Apache::TestRunPerl" at /home/r2/work/Apache-ModSSL/t/TEST line 31.

                            Also grepping the source did not reveal something useful:

                            r2@opi:/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/Apache> grep -i reconfigure Test*.pm
                            TestConfig.pm: $self->{clean_level} = shift || 2; #2 == really clean, 1 == reconfigure
                            TestConfig.pm: # we probably could reconfigure on the fly ($self->configure), but
                            TestRun.pm: # reconfigure or not.
                            TestRun.pm: $self->{reconfigure} = $opts{configure} ||
                            TestRun.pm: if ($self->{reconfigure}) {
                            TestRun.pm: delete $self->{reconfigure};
                            TestRun.pm: #if config is cached and MaxClients == 1, must reconfigure
                            TestRun.pm: warning "server is reconfigured for proxy";

                            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.

                            Torsten
                          • Stas Bekman
                            ... Sorry, I should have said just reconfigure , which is not a method. Just to spot the code in charge to forcing reconfiguration. ... right, but the idea
                            Message 13 of 14 , Dec 19, 2004
                            • 0 Attachment
                              Torsten Foertsch wrote:
                              > On Thursday 16 December 2004 17:28, Stas Bekman wrote:
                              >
                              >>grep the source for reconfigure() which I think will enforce the re-cache.
                              >
                              >
                              > Sorry, I could not find it. Simply changing refresh to reconfigure yields:

                              Sorry, I should have said just 'reconfigure', which is not a method. Just
                              to spot the code in charge to forcing reconfiguration.

                              > Can't locate object method "reconfigure" via package "Apache::TestRunPerl" at /home/r2/work/Apache-ModSSL/t/TEST line 31.
                              >
                              > Also grepping the source did not reveal something useful:
                              >
                              > r2@opi:/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/Apache> grep -i reconfigure Test*.pm
                              > TestConfig.pm: $self->{clean_level} = shift || 2; #2 == really clean, 1 == reconfigure
                              > TestConfig.pm: # we probably could reconfigure on the fly ($self->configure), but
                              > TestRun.pm: # reconfigure or not.
                              > TestRun.pm: $self->{reconfigure} = $opts{configure} ||
                              > TestRun.pm: if ($self->{reconfigure}) {
                              > TestRun.pm: delete $self->{reconfigure};
                              > TestRun.pm: #if config is cached and MaxClients == 1, must reconfigure
                              > TestRun.pm: warning "server is reconfigured for proxy";

                              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.

                              --
                              __________________________________________________________________
                              Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                              http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                              mailto:stas@... http://use.perl.org http://apacheweek.com
                              http://modperlbook.org http://apache.org http://ticketmaster.com

                              --
                              Report problems: http://perl.apache.org/bugs/
                              Mail list info: http://perl.apache.org/maillist/modperl.html
                              List etiquette: http://perl.apache.org/maillist/email-etiquette.html
                            • Torsten Foertsch
                              Hi, this is quite an old thread. But now I have found why it was not working. ... [...] ... Let s start with a short explanation what I was trying to do. I
                              Message 14 of 14 , May 1, 2005
                              • 0 Attachment
                                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
                              Your message has been successfully submitted and would be delivered to recipients shortly.