You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/01/22 11:46:21 UTC
[mp2] changing Apache->server
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.
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.
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. That should be a doable thing
during the server startup, we can just have another global value and
reassign it to a different host every time we are inside <perl> sections,
perlmodule and perlrequire modperl_cmd handlers. it's somewhat similar to
flipping the perl context.
The problem is what to do about it in the latter stages. post_config and
open_logs phases receive only the base server object. And to access the vhosts
one will need to traverse the servers chain via $s->next. So here
Apache->server will be the base server.
It becomes very tricky and expensive during request time, and I'd rather have
us not maintain Apache->server here, since we already have it in $r->server.
The bottom line is that we need a way to access vhost $s objects during the
startup time (and may be shutdown?) and have this feature not working anywhere
else. So may be we should leave Apache->server alone and devise a new API for
Apache->current_server which will be available only during the server startup?
Ideas?
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] changing Apache->server
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] changing Apache->server
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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.
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.
> 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?
>
> 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.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org