A relatively trivial point, but I notice that the pod files
cgi_to_mod_perl.pod
mod_perl.pod
mod_perl_tuning.pod
which were supplied with mod_perl 1 are missing from mod_perl 2
(perhaps because they need re-writing?)
Is it indended to include these in the final mod_perl 2 release?
Thanks
Don't mess with the cooker, try using a subclass, e.g.:
# ModPerl/RegistryPrefork.pm
package ModPerl::RegistryPrefork;
use strict;
use warnings FATAL = 'all';
our $VERSION = '0.01';
use base qw(ModPerl::Registry);
use File::Basename ();
sub handler : method {
my $class
--- Stas Bekman [EMAIL PROTECTED] wrote:
This seems to work OK. Hopefully I should now be able to remove the
mod_perl 1's Registry.pm file.
Thanks everyone.
Perfect. I've replaced the suggestion to use mp1's Apache::Registry
with this
better solution, which doesn't require mp1:
I'm steadily making progress with getting a collection of mod_perl 1
compatibale scripts working with mod_perl 2 using the backward
compatibility mode.
However, I find that the working directory of all scripts is /. This
occurs for both ModPerl::Registry and Apache::Registry. This causes
many
--- Stas Bekman [EMAIL PROTECTED] wrote:
... I won't commit it yet, but you can override it in your
startup.pl,
until the dust settles down:
require Apache::compat;
sub Apache::RequestRec::chdir_file {
my $dir = @_ == 2 ? $_[1] : $_[0]-filename;
chdir $dir;
}
Thanks Stas.
... and even stranger, when I invoke the printenv cgi script for the
FIRST time it STILL displays / for the working directory, but if I
then click the IE browser's refresh (or CTRL-Refresh) button it changes
to the server root /dir1/dir2/httpd. Subsequent clicks of the refresh
button continue to
Thanks Stas that worked a treat, except that your call to
File::Basename::basename
should be
File::Basename::dirname
The strange reversion to / seems to have been cured too.
Colin
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design
Can you please post a working solution, so I'll add it
to docs.
I added this to my startup.pl just after the
use Apache::compat();
sub Apache::RequestRec::chdir_file {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-filename;
my $dir = File::Basename::dirname($file);
I'm trying to get some perl scripts that work OK under mod_perl 1
working in mod_perl 2. I'm therefore using the mod_perl 1 backward
compatiblity, and also the Apache::Registry from mod_perl 1 (as
described in the mod_perl 2 documentation to get around the chdir()
problem).
One of the scripts
--- Stas Bekman [EMAIL PROTECTED] wrote:
Stas Bekman wrote:
ColinB wrote:
One of the scripts sets up a request handler, but when it tries to
execute:
$r-cgi_env(AB_AUTHHOST=$host);
I have never used that API, but I believe you misuse it. I think it
should be:
$r
--- Stas Bekman [EMAIL PROTECTED] wrote:
ColinB wrote:
So how can I go about installing just Apache::Registry from the
mod_perl 1 tar file without having to install ALL of mod_perl 1 ?
simply copy it into one of the dirs in your @INC.
You will also need to load Apache::compat
This page:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends
says that mod_perl 2's ModPerl::Registry does not chdir() into the
script's directory, wheras mod_perl 1's Apache::Registry DOES chdir().
It also says that this will eventually
What is the preferred method of compiling mod_perl - static or dynamic?
I have read that *static* linking is likely to load and execute faster,
but may be wasteful of resources if there are multiple proceses each
with its own copy of the common code.
It therefore seems likely that a statically
Thanks for the comments. I guess I'll just have to stick with the
dynamically-linked mod_perl 2.0 for the time being.
I'll keep checking the mod_perl 2.0 site pages and pick up a
static-capable version when it becomes available.
Colin
__
Do you
14 matches
Mail list logo
