httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Myers <...@sumthin.nu>
Subject Re: multiple configurations
Date Tue, 15 Jan 2002 03:01:00 GMT
On Jan 14, 2002 at 13:02:20 +0800, Stas Bekman wrote:
> 
> Rick Myers wrote:
> 
> > On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
> > 
> >>Rick Myers wrote:
> >>
> >>
> >>>This may sound silly, but is there an *easy* way to test
> >>>multiple server config's?
> >>>
> >>>For example, I have a perl module that defines a new
> >>>RSRC_CONF directive that I want to test in every possible
> >>>way. To do that I need one server with no use of the module
> >>>(to validate the test, I guess), one server that uses the
> >>>directive in only the global area, and others for various
> >>>combinations of global vs. virtual use.
> >>>
> >>>The only way I can see to make this happen is to write
> >>>various extra .conf.in's and remove includes from the
> >>>httpd.conf file as each test runs. To make it work I have to
> >>>HUP the server after editing httpd.conf in each test, but
> >>>while using -X the server just dies.
> >>>
> >>>I managed to figure out a way around -X and keep the server
> >>>alive beyond the HUP, but it's a real pain. The end result
> >>>is overloading Apache::Test::config,
> >>>Apache::TestConfig::new_test_server, and
> >>>Apache::TestRunPerl::new_test_config -- all just to get back
> >>>to the point where I can finally overload
> >>>Apache::TestServer::start_cmd and leave out the $one.
> >>>
> >>>Thoughts?
> >>>
> >>I think you can do it using a set of a several .pm response handlers. 
> >>Since the __DATA__ section is used to configure the server for the 
> >>handler in the same file, you could write a single handler and then 
> >>create a number of .pm files each having a different config section in 
> >>its __DATA__ section as a virtual host, so they can all co-exist in the 
> >>without restarting the server.
> >>
> > 
> > That was my original thought also, but given the number of
> > tests I'm looking at I don't think I want to spend the next
> > couple years coding it. At last count there were almost 2400 tests
> > spread across 7 scripts.
> 
> 
> I think the first thing to figure out is whether you can have all the 
> desired configuration co-exist using VirtualHosts, so you won't need to 
> restart the server. I think you should be able to accomplish that.
> 
> Once you do, I can think of many .pm response handlers include some 
> httpd.conf bits in various VirtualHosts. So you can re-use these.

Been there. :)

# global
NewDirective On
<VirtualHost 1.2.3.4>
	ServerName foobar
	NewDirective Off
</VirtualHost>
<VirtualHost 1.2.3.4>
	ServerName bazbam
</VirtualHost>

vs.

# global
NewDirective Off
<VirtualHost 1.2.3.4>
	ServerName foobar
	NewDiretive Off
</VirtualHost>
<VirtualHost 1.2.3.4>
	ServerName bazbam
</VirtualHost>

In each case, how should the bazbam virtual react? And the
better question (and the reason for testing) is, will my
module do what it's supposed to do? I don't see much way
around restarting the server to test for that.

> >>Another alternative I can think of is writing one big .conf.in file with 
> >><IfDefine> sections and allow t/TEST to have path-thru options to enable

> >>-D flags, so without changing the configuration you could run:
> >>
> >>t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;
> >>
> > 
> > Hmm.. Now that's interesting. I don't quite follow the
> > path-thru options bit though. I understand passing the -D's
> > to the server, but wouldn't that still mean you'd have to
> > restart it in mid-test?
> 
> 
> Yup, that's what I've suggested. In my example above you run t/TEST 3 
> times invoking three different configurations. The path-through option 
> doesn't exist yet, though.
>
>
> > If that's what you're saying, I have to admit I like the
> > thought of letting the test suite do the restarting as
> > opposed to just crossing my fingers and hoping nothing goes
> > wrong with my SIGHUP. Not to mention being able to forget
> > about all the monkey-motion I'm doing with overloading.
> 
> Well, the test suite doesn't restart the server now.

Sorry, but you've lost me now.

Running t/TEST myself will be three seperate test runs and
muck up a normal ``perl Makefile.PL && make && make test &&
make install''.

Letting the test suite run itself three times though still
isn't going to do what you suggest, since it doesn't restart
the server. The server won't recognize the IfDef's until it
restarts, right?

Rick Myers                            rik@sumthin.nu
----------------------------------------------------
The Feynman Problem       1) Write down the problem.
Solving Algorithm         2) Think real hard.
                          3) Write down the answer.

Mime
View raw message