pod files

2003-08-14 Thread ColinB
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

Colin


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-30 Thread ColinB
 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 = (@_ = 2) ? shift : __PACKAGE__;
  my $r = shift;
  return $class-new($r)-default_handler();
 }
 
 sub chdir_file {
  use File::Basename();
  my $file = @_ == 2 ? $_[1] : $_[0]-{FILENAME};
  my $dir = File::Basename::dirname($file);
  chdir $dir or die Can't chdir to $dir: $!;
 }
 
 1;

I copied this into a new file RegistryPrefork.pm in the same
directory as the ModPerl Registry.pm in the perl tree, and changed the

   PerlResponseHandler ModPerl::Registry

line in startup.pl to

   PerlResponseHandler ModPerl::RegistryPrefork

and restored the RegistryCooker.pm file to its original contents. I
also removed the Apache::RequestRec::chdir_file definition in my
startup.pl

This seems to work OK. Hopefully I should now be able to remove the
mod_perl 1's Registry.pm file.

Thanks everyone.

Colin


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-30 Thread ColinB

--- 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:
 

http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends

I'm a little confused about the changes you've made here. You still
mention using Apache::Registry, and then you added the text that
describes ModPerl::RegistryPrefork but then use it via

PerlResponseHandler Apache::RegistryPrefork




__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Working directory of script is / !

2003-07-29 Thread ColinB
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 scripts to fail because they call open() using a relative
pathname.

Surely the working directory of a script should be the directory in
which it resides?

It does not seem to matter what directory I am in when I invoke httpd;
the script's current directory is always /.

I am mystified.

Here is the output from a simple printenv cgi script (with some of
the env variables snipped for brevity), which also prints the working
directory using getcwd (and invokes ld -al to list the contents of
the current directory):

Content-type: text/plain

DOCUMENT_ROOT=/dir1/dir2/httpd/htdocs
EXITSERVERLOC=http://localhost/cgi-bin/index.cgi;
GATEWAY_INTERFACE=CGI-Perl/1.1
HOME=/mps/home/cdi
HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/msword, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/x-shockwave-flash, */*
HTTP_ACCEPT_ENCODING=gzip, deflate
HTTP_ACCEPT_LANGUAGE=en-gb
HTTP_CONNECTION=Keep-Alive
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
MOD_PERL=mod_perl/1.99_09
QUERY_STRING=
REQUEST_METHOD=GET
REQUEST_URI=/cgi-bin/printenv
SCRIPT_FILENAME=/dir1/dir2/httpd/cgi-bin/printenv
SCRIPT_NAME=/cgi-bin/printenv
SERVER_PORT=8000
SERVER_PROTOCOL=HTTP/1.1
SERVER_SIGNATURE=addressApache/2.0.46 (Unix) mod_perl/1.99_09
Perl/v5.8.0 Server at homer Port 8000/address\n
SERVER_SOFTWARE=Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0
TZ=GB

Working directory is /
total 329

drwxr-xr-x  36 root root1024 Jul 16 09:50 .
drwxr-xr-x  36 root root1024 Jul 16 09:50 ..
lrwxrwxrwx   1 root root   9 Jun 19 09:59 bin - ./usr/bin
drwxr-xr-x   2 root root 512 Jun 27 14:42 cdrom
drwxr-xr-x  16 root sys 4608 Jun 27 15:44 dev
drwxr-xr-x   4 root sys  512 Jun 19 10:28 devices
drwxr-xr-x  51 root sys 3584 Jul 18 14:04 etc
drwxr-xr-x   3 root sys  512 Jun 19 09:57 export

and so on...


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-29 Thread ColinB
--- 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. However, this seems to set the working directory to the
server root, not the cgi-bin directory where the script resides. For
example, my printenv script now displays:

...
SCRIPT_FILENAME=/dir1/dir2/httpd/cgi-bin/printenv
SCRIPT_NAME=/cgi-bin/printenv
...
Working directory is /dir1/dir2/httpd
total 54

drwxrwxr-x  15 sxi_user other512 Nov 28  2001 .
drwxrwxr-x   4 sxi_user sxi  512 Jul 29 10:58 ..
drwxrwxr-x   2 sxi_user sxi  512 Jul 18 15:57 bin
drwxrwxr-x   2 sxi_user sxi  512 Jul 18 15:57 build
drwxrwxr-x   9 sxi_user sxi 1024 Jul 29 11:38 cgi-bin
drwxrwxr-x   2 sxi_user sxi  512 Aug 16  2000 conf
...



__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-29 Thread ColinB
... 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 show the server root.

Howvever, if I leave the browser inactive for about 30 secs or so and
then click refresh again, I get the working directory / again.
Sunsequent rereshes display the server root pathname again.

Very strange.

Colin


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-29 Thread ColinB
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 software
http://sitebuilder.yahoo.com


Re: Working directory of script is / !

2003-07-29 Thread ColinB
 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);
chdir $dir or die Can't chdir to $dir: $!;
}


 
 BTW, perhaps we should enable the chdir_file call in
 ModPerl::RegistryCooker, 
 so people won't need to install mod_perl 1 just to have
 Apache::Registry... 
 can you please try with ModPerl::RegistryCooker?

Well I commented out the following line in 
perl/lib/site_perl/5.8.0/sun4-solaris/Apache2/ModPerl/RegistryCooker.pm
like this:

#*chdir_file = \NOP;

and added an identical definition to the above in my startup.pl file
like this:

sub ModPerl::RegistryCooker::chdir_file {
use File::Basename();
my $file = @_ == 2 ? $_[1] : $_[0]-filename;
my $dir = File::Basename::dirname($file);
chdir $dir or die Can't chdir to $dir: $!;
}

and then in my httpd.conf I replaced

   PerlResponseHandler Apache::Registry

with

   PerlResponseHandler ModPerl::Registry

and then re-started the server.

But the printenv script just displays the working directory as /.

Perhaps I've done this wrong? I did notice a couple of lines in the
RegistryCooker.pm file that were already commented out, like this:

  #XXX: $self-chdir_file($Apache::Server::CWD/);

I don't know if that's significant?


Colin



__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Can't locate object method cgi_env

2003-07-28 Thread ColinB
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 sets up a request handler, but when it tries to
execute:

$r-cgi_env(AB_AUTHHOST=$host);

the following error appears in the httpd log file:

Can't locate object method cgi_env via package Apache::RequestRec
at /path/to/perl/lib/site_perl/Apache/MyModule.pm line 55

I have tried to search the perl.apache.org site for cgi_env, but no
matches found.

I have also tried to search all of the files in the perl 5.8.0 and
mod_perl 2 distribution for occurences of cgi_env, and the ONLY place
it occurs is in mod_perl-1.99_09/todo/deprecated_features.txt which
lists several $r methods (including $r-cgi_env) and says that:

these features will either:
a) never be in 2.0
b) only be in if #ifdef MP_DEPRECATED
c) be in a form that was nothing like 1.xx
d) split off into something standalone on cpan


So if $r-cgi_env has been REMOVED from mod_perl 2, what is the
recommended alternative for it?

Thanks,

Colin


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Can't locate object method cgi_env

2003-07-28 Thread ColinB
--- 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-subprocess_env(AB_AUTHHOST=$host);
  
  which works in mp1 and mp2.

Thanks Stas. That seems to have fixed that problem.

 I'm going to commit this (in case you don't want/can't
 s/cgi_env/subprocess_env/)
 snip

Thanks again. This is all pretty new to me and I'm not (yet) familiar
with the procedures for submitting changes to source or documentation.

Colin


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


Re: Apache::Registry in mod_perl 2

2003-07-17 Thread ColinB

--- 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 for it to work.
 

Thanks. I've untarred mod_perl 1.0 and searched for any Registry*
filnames:

./lib/Apache/RegistryBB.pm
./lib/Apache/RegistryNG.pm
./lib/Apache/Registry.pm
./lib/Apache/RegistryLoader.pm

Do I need to copy ALL of these files (and maybe others?) or just the
./lib/Apache/Registry.pm  file?




__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


Apache::Registry in mod_perl 2

2003-07-15 Thread ColinB
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 be fixed by the time mod_perl 2
is released, and in the meantime you can use the Apache::Registry
(which is part of mod_perl 1) in mod_perl 2.

As I will be trying to get some old scripts working in mod_perl 2, it
seems prudent to use Apache::Registry.

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 ?

Colin


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


Is statically-compiled mod_perl better?

2003-07-03 Thread ColinB
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 compiled mod_perl would be
faster, provided that a large number of httpd's are not being run at
the same time.

Is this correct?

It seems that at present it is not possible to build mod_perl 2.0
statically. It can only be built dynamically and loaded using
LoadModule in httpd.conf. This seems strange if the preferred method of
building is static.

Thanks

Colin



__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


Re: Is statically-compiled mod_perl better?

2003-07-03 Thread ColinB
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 Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com