On Wed, 8 Aug 2001, Stas Bekman wrote:
> Listen 8555
> <VirtualHost _default_:8555>
you don't want to hard code the vhost port, see
t/filter/TestFilter/input_msg.pm
> PerlOptions +Parent
and this is only available with ithreads+threaded mpm. we need to start
the server with -DTHREADED_MPM or similar so this can be done
conditionally.
> PerlSwitches -Mlib=@serverroot@
> PerlSwitches -Mblib=@serverroot@
> PerlSwitches -Mlib=@serverroot@/lib/vh
> PerlSwitches -Mlib=@serverroot@/hooks
> PerlSwitches -Mlib=@serverroot@/response
> PerlRequire conf/modperl_extra.pl
> PerlModule PerlModuleTest
>
> <Location /TestModules::dump_env>
> # PerlOptions +GlobalRequest
> SetHandler perl-script
> PerlResponseHandler TestModules::dump_env
> </Location>
>
> </VirtualHost>
>
> it is quite cumbersome :(
how about if you leave PerlSwitches as is so they are inherited, instead
of PerlModule, add a PerlRequire:
use lib 'path/for/vhost';
use PerlModuleTest ();
> $buffer .= sprintf "%s\n", $_;
$buffer = "$_\n";
> Now do we really need tests for Perl{Require|Module}? Can anything go
> broken with these? As they are pure Perl and don't rely on any
> environment.
it would be nice to have tests for them, but if its too much trouble for
now, they can always be done later.
> Doug, you said that .htaccess should support these two directive as well,
> but 'eval "expr"' (the way modperl_require is implemented) would be very
> inefficient?
same as 1.x. PerlModule can be made more efficent using Perl_load_module.
> In any case, why do we want to support old features that don't make sense?
> Or do they? Why would you want this feature in first place?
people have asked for it in the past, i think because they don't have
write access to the main httpd.conf.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
