Rick Myers wrote:
On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
Rick Myers wrote:
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.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?
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.
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.
_____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
