Stas Bekman wrote:
If you have followed the end of the long story on windows with free to wrong pool, you'd have known that one of the reason for the problem was the use of the wrong context in add_config in the following snippet:
<VirtualHost _default_:8530> PerlOptions +Parent <Perl> use Apache::ServerUtil; my $s = Apache->server; $s->add_config(['PerlModule TestVhost::basic']); </Perl> </VirtualHost>
The problem is that Apache->server returns the base server, and
add_config tries to use the base server's perl context for all the
config directives.
right. the answer here is "don't do that." that is, don't use the base server to add configurations to vhosts.
that's a wrong answer, IMHO. <Perl> sections and PerlRequire should work identically. The right answer is that the API to get $s for vhost is needed.
but $s->add_config ought to be just fine when called from a PerlRequire directive outside of any <VirtualHost> containers, which ought to add directives to the main server. if it doesn't, or if using it from <Perl> sections is different than using it from a startup.pl, then it's a bug (sort of) separate from all of this.
I have never used vhosts with mp1 so I'm not even sure how did it work in mp1. It probably was never an issue because the server was "monolithic" in a sense of having all modules loaded into the same perl interpreter. But still something had to be done to handle vhost configs.
PerlRequire/PerlModule is exactly the same as <Perl> sections, so as you don't have a way to access a vhost's $s inside <perl> sections you can't do that in required modules. It's not a bug, it's just a missing API.
when it should use the vhost's one (because of PerlOptions +Parent). That means that 'PerlModule TestVhost::basic' gets loaded by the parent server which is not what we want. due to other issues with multiple perl pools, the vhost will eventually load this module too, but it must be not loaded by the base server.
outside of all of this, can you really scope PerlModule like that? in mp1 PerlModule was global in scope. I guess now it's possible to allocate interpreters specific to vhosts, so now we can restrict module usage to a vhost as well?
Yes, and it works. We have lots of tests testing just that.
I'm not sure how to deal with it. I was thinking to change the meaning of Apache->server to be equivalent to Apache->request - i.e. it should return the current server and not the base server (unless the current server is the base server). and have a new API for the base server.
I think Apache->server should always return the base server, allowing you to iterate over the servers. the problem is knowing which server is the right vhost as you iterate over it. you could probably use $s->server_hostname if you have a ServerName set up for the host, but that's not guaranteed. so, I like the idea of Apache->current_server, which would be guaranteed to give you the server_rec from the current vhost.
the problem is the same as with maintaing the pool "global, but not pconf" object I've suggested in the other thread. You need to maintain yet another global variable and assign it every time a perl interpreter is selected or perl context is switched. I think using PL_modglobal will do the storage trick here.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
