Hi Group,
I have a need to access all the %ENV (cgi,mod_perl sent by the client)
variables prior to invoking the content handler. I am using the modperl
environment by running the cgi scripts under Perl::Registry. I wish to
use the PerlTransHandler to check if the request for page A has
orginated
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
I have used the following code in the in my handler and I still do not
get the values.
Do you get anything at all? HTTP_REFERER is not always sent by
browsers.
- Perrin
Only PERL_SEND_HEADER=On. No other env. variables.
I did run tests by clicking on links to check to see if the HTTP_REFERER
is being set.
Mark.
On Thu, 2003-07-31 at 16:15, Mark Deepak Puttnam wrote:
Only PERL_SEND_HEADER=On. No other env. variables.
And you haven't turned off PerlSetupEnv in your httpd.conf?
- Perrin
On Thu, 2003-07-31 at 15:44, Mark Deepak Puttnam wrote:
sub handler {
my $r=shift;
my $env=$r-subprocess_env;
%ENV=%$senv;
my $referer=$ENV{'HTTP_REFERER'};
x
}
Come to think of it, you should just use the Apache API for this:
my
I did not have that directive in my config before. But now,I set it
explicitly to PerlSetupEnv On , still no env variables other than the
PERL_SEND_HEADER=On.
Mark
Hi Perrin,
my $referer = $r-header_in(Referer);
Thanks, the above statement did give me the value.
Mark
Hello,
I have a question.
If I have a $dbh global variable in a particular module that I 'use'. I know
that Apache::DBI will give a cached connection to the module to use.
But what if I do something like $dbh-commit();
Is it possible that I am committing data for another session by accident?
On Fri, 2003-07-25 at 14:55, Levon Barker wrote:
If I have a $dbh global variable in a particular module that I 'use'. I know
that Apache::DBI will give a cached connection to the module to use.
There is no need to use a global. Apache::DBI caches it for you. If
you put it in a global, then
In this project I'm making (database), I have several variables with a
potential for a large amount of information to be held in them.
They're all hashes. Some are hashes of hashes...
There is a tech_list, which holds information about each technician.
There is a queue_list which holds an ID
Dennis Stout wrote:
Is there a way I could get these variables populated on server start and never
loaded again unless the database was changed? So in my subroutine for posting
an event that changed it I could call repopulate_queue_hash and have it redo
the hash, so changes still happened without
Is there a way I could get these variables populated on server start and
never
loaded again unless the database was changed? So in my subroutine for
posting
an event that changed it I could call repopulate_queue_hash and have it
redo
the hash, so changes still happened without a restart
Dennis Stout wrote:
So in startup.perl put
my %queue_list = list_queues;
my %tech_list = list_techs;
and so on?
Then each process would get a copy of the hash?
No, those are lexicals, not globals. Something like this:
package MyCompany::Globals;
use vars qw(%queue_list %tech_list);
%queue_list
I'm not able to get *any* variables out from the apache server
environment. As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r-uri;
return unless $r-is_main
On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
I'm not able to get *any* variables out from the apache server
environment.
Did you try the normal $ENV{'VARIABLE'} approach?
- Perrin
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way. Thanks for the
suggestion though!
--Ryan
On Mon, 2003-06-09 at 13:41, Perrin Harkins wrote:
On Mon
IF you're using mp2...in your httpd.conf are you setting up the handlers
with modperl or perl-script? The former doesn't provide any environment
variables:
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
I don't believe this applies to mp1.
mma
-Original
I'm using mod_perl 1. But I'm setting the handlers in httpd.conf. I
sent a message to the list on thursday (problem with pulling variables
from mod_ssl) that more fully describes my situtation.
--Ryan
On Mon, 2003-06-09 at 14:31, Marc M. Adkins wrote:
IF you're using mp2...in your
On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way. Thanks for the
suggestion though!
Okay. And you're certain
any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
--Ryan
On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
Ryan Muldoon wrote:
I'm not able to get *any
environment variables can't be accessed that way. Thanks for the
suggestion though!
Okay. And you're certain that a simple $r-subprocess_env('VARIABLE')
doesn't work? Have you tried setting a variable yourself as a test with
PerlSetEnv in httpd.conf?
- Perrin
Ryan,
Ust out of curiosity, at what stage in the request chain are you doing
this? If you are doing anything before mod_ssl populates its environment
variables (which I seem to rembmer being at Fixup, although I may be
confusing with something else), you wouldn't be able to access them. You
SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
Do you have a
SSLOptions +StdEnvVars
directive inside
mod_ssl does not (but mod_cgi and mod_perl both do).
the problem you're seeing is that these variables are setup during the fixup
phase, so in using a PerlAuthenHandler you're trying to see them too early.
int ssl_hook_Fixup(request_rec *r)
{
SSLSrvConfigRec *sc = mySrvConfig(r-server
reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
Do you have a
SSLOptions +StdEnvVars
directive inside the relevant location of your httpd.conf?
Goldstand wrote:
Ryan,
Ust out of curiosity, at what stage in the request chain are you doing
this? If you are doing anything before mod_ssl populates its environment
variables (which I seem to rembmer being at Fixup, although I may be
confusing with something else), you wouldn't be able
to make any kind of difference.
Ryan To make sure it isn't just mod_ssl being lame for some reason, I've
Ryan tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
Ryan avail. :(
That takes the enviroment variables that apache was started with
and passes those to mod_perl
see, that's not entirely true. they are set in
subprocess_env where they sit and wait, presumably for somebody else to call
add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
the problem you're seeing is that these variables are setup during the fixup
phase, so
On Mon, 2003-06-09 at 15:35, Geoffrey Young wrote:
no, I wasn't saying that :) subprocess_env() from the main request is the
right way to go. I was just trying to let you know that it has nothing to
do with %ENV really.
I wouldn't go that far. %ENV does get populated with that stuff, just
Ok, removed. Thank you very much for the in-depth replies. It is very
useful. Unfortunately any variable-reading continues to elude me. But
I really appreciate all the help!
well, it sounds like you are having a larger problem that just mod_ssl-based
variables.
since you mention you're
Actually, upon flushing my browser cache and checking again, I can in
fact read the MOD_PERL environment variable just fine. But still no
luck on any mod_ssl related variables.
--Ryan
[ Please keep it on the list. ]
On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
Ryan, can you post a more complete code example?
- Perrin
Here it is:
package Apache::AuthNx509;
use strict;
use Apache::Constants qw(:common);
use Text::ParseWords qw(quotewords);
use Apache::Log
On Mon, 2003-06-09 at 15:24, Perrin Harkins wrote:
[ Please keep it on the list. ]
Sorry about that!
On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
Ryan, can you post a more complete code example?
- Perrin
Here it is:
package Apache::AuthNx509;
use strict;
use
I'm trying to write an apache authentication module that uses client
certificates for authentication. Basically, all I'm trying to do is use
what mod_ssl does for cert verification, and then set REMOTE_USER. I
wrote to the list last week about a segfault, which was resolved thanks
to the help you
Greetings again.
I'm trying to figure out the best/fastest/most elegant way of setting
virtualhost based variables. Basically I have three sites, and the only
difference between them is the DocumentRoot ($htdocroot) and the database
their data is being accessed from ($dbh).
When
Alan [EMAIL PROTECTED] wrote:
Greetings again.
I'm trying to figure out the best/fastest/most elegant way of setting
virtualhost based variables. Basically I have three sites, and the only
difference between them is the DocumentRoot ($htdocroot) and the database
their data is being accessed
On Wed, Oct 02, 2002 at 06:04:03PM -0500, James G Smith wrote:
Alan [EMAIL PROTECTED] wrote:
Greetings again.
I'm trying to figure out the best/fastest/most elegant way of setting
virtualhost based variables. Basically I have three sites, and the only
difference between them
to the original request. If this
original request was for a mod_perl module, then it doesn't recieve
it's appropriate INC. The environment variables are all set properly,
ie: PERL5LIB is what is supposed to be, it's just that the INC hasn't
be rebuilt.
Does anyone know if this is a bug in mod_perl? I
I'm sure someone will correct me if I'm wrong...
But, variables in the initial section (ie outside of a function) in the main
package will stay in scope all the time. This means that it will retain the
value from a previous request- which might be giving you these problems.
As Perrin Harkins
$auth_type = $r-auth_type;
$cookie=$auth_type-key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(//, $buffer);
foreach my $pair (@pairs) {
}
What I am doing wrong? Everytime the script runs the
values of the variables coming in change
ey; ($user,$hash)=split(/:/,$cookie); read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'}); my @pairs = split(//, $buffer); foreach my $pair (@pairs) { } What I am doing wrong? Everytime the script runs the values of the variables coming in change. Should I use the delete function and delete all
darren chamberlain wrote:
Make those global symbols ($cookie, $user, and $hash) lexical (declare
with my) and the code will both compile and do what you expect (i.e.,
not maintain values from call to call).
That's what I was thinking too. Also, it's really not a good idea to do
your own
Sorry, There is a my in front of the ($cookie,$user)
code. I am confused about your second statement about
parsing the input. What should I be doing? Do you
mean I should use $r-read($content,
$r-header_in('Content-length'))? to read in the
variables?
I use the AuthCookie modules to set
On Tue, 13 Aug 2002, Michael Drons wrote:
Date: Tue, 13 Aug 2002 07:46:16 -0700 (PDT)
From: Michael Drons [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Perrin Harkins [EMAIL PROTECTED],
darren chamberlain [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: variables not changing
Ken Y. Clark wrote:
As for this and Perrin's comment about parsing on your own, the point
is that you've written a lot of code that has already been written and
debugged by a lot of really smart people. There's no reason for you
to be reading STDIN and spliting and all that. If you're using
I am using Apache::Registry (Apache 1.3.26) I am see
weird things happen with my scripts. I have have use
strict in all of the scripts and I use my() for all
of my variables. But I still have variables that
contain data from previous loads. I see it in hashes
and arrays. Especially, if I have
(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(//, $buffer);
foreach my $pair (@pairs) {
}
What I am doing wrong? Everytime the script runs the
values of the variables coming in change. Should I
use the delete function and delete all of the
variables
, it this some
mod_perl specific feature to just eat up some variables, or what?
Here are cut-down versions of my modules:
Site.pm:
-
package Site;
use strict;
use Apache::Log;
sub handler {
my $r = shift;
use vars qw( $log
Viljo Marrandi actually wrote:
my $r = shift;
use vars qw( $log );
$log = $r-log();
if ( $some_case eq 'true' ) {
use Sub::First qw( $log );
I haven't tested, but this doesn't look as a good idea.
I don't think your code does what you think it does
(or what you think it
The answer to the trick question is that the subroutine name in package
Sub::First is misspelled (missing a t).
However, I think I would provide the Apache::Log object as a parameter to
new() rather than twiddling with package vars to try to have it magically
updated by Exporter. For example:
Stas Bekman wrote:
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
the existing inctances' ENV is not clobbered.
My guess is that a
I thought that using 'local' would successfully scope those globals to
within a sub, so you could,k for example, slurp an entire file by doing:
local $/ = undef;
my $file = FH;
Or am I wrong in that? I use it frequently, and don't seem to have any
troubles.
--Jon R.
It is my
You'll also need to use a PerlPassEnv directive prior to your Perl block.
For debug purposes, try adding the following inside your Perl block:
print join(\n, map { $_ = $ENV{$_} } (keys %ENV)), \n;
OR, my personal quick-debugging catch-all:
use Data::Dumper;
print Dumper \%ENV;
You'll be
DA FC 06 AB 4C D6 A4 DE 03 E0 77 D6 DE E0 73
PGP public key available by fingering [EMAIL PROTECTED]
On Fri, 3 May 2002, Bill Catlan wrote:
Hello,
The online mod_perl guide
(http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
ml) states:
Special Perl variables
troubles.
Okay, local takes a temporary copy of the variable and then restores the
original value at the end of the block. It's the same variable though. my
creates a new variable that is only visible from within the block and
can't be seen from other subroutines. With my there are two variables
Bill Catlan wrote:
Stas Bekman wrote:
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
the existing inctances' ENV is not
Bill Catlan wrote:
Hello,
The online mod_perl guide
(http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
ml) states:
Special Perl variables like $| (buffering), $^T (script's start time), $^W
(warnings mode), $/ (input record separator), $\ (output record
What I was really looking for was $r-server_root_relative. =) Thanks
Geoff!
That's to all for your help.
-Fran
You'll also need to use a PerlPassEnv directive prior to your Perl
block.
For debug purposes, try adding the following inside your Perl block:
print join(\n, map { $_ =
On Wednesday, May 1, 2002, at 05:04 AM, Fran Fabrizio wrote:
I spoke too soon.
I need:
Perl
push Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-
bin/chimpkit/) ];
/Perl
This does not appear to be possible because there's no way to
pass in SERVER_ROOT to the apache startup.
I am trying to make a portable mod_perl.conf. I have things like:
Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/
Location /cgi-bin/chimpkit/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
/Location
which really needs
Yup. See the perl directive. Good description of how it works in
the Eagle Book.
-- Fran Fabrizio [EMAIL PROTECTED]
I am trying to make a portable mod_perl.conf. I have things like:
Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/
Location /cgi-bin/chimpkit/
SetHandler
Yikes, I just found an example of the exact thing I needed in the
cookbook (recipe 2.16). Sorry, and thanks!
-Fran
I spoke too soon.
I need:
Perl
push Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
/Perl
This does not appear to be possible because there's no way to pass in SERVER_ROOT to
the apache startup. I have SERVER_ROOT
getting set in root's .bashrc, but when I execute
Fran Fabrizio wrote:
I spoke too soon.
I need:
Perl
push Alias, [ qw(/cgi-bin/chimpkit/
$ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
/Perl
This does not appear to be possible because there's no way to pass in
SERVER_ROOT to the apache startup. I have SERVER_ROOT getting set in
In my httpd.conf I have set 'PerlSetVar UseStrict 1' because I always use
sctict anyway and I see in the docs that this might become the default
too. So I always declare my variables with my().
Suppose I have a master ASP file that includes other scripts and these
other scripts need access
'PerlSetVar UseStrict 1' because I always use
sctict anyway and I see in the docs that this might become the default
too. So I always declare my variables with my().
Suppose I have a master ASP file that includes other scripts and these
other scripts need access to the variables declrared
. So I have defined the variable as a package level variable.
Package level variables are shared upon fork(), in the sense that
the memory segment(s) they use is made available to all child
processes. BUT the memory itself isn't shared, and any subsequent
write to the variable in one of the children
-Original Message-
From: Chui G. Tey [mailto:[EMAIL PROTECTED]]
package Apache::MyPkg;
my $COM_instance;
sub handler {
if (!$COM_instance) {
$COM_instance = Win32::OLE-new(ProgID.Class);
}
}
Will the different child processes created by Apache share the
I have some state data that I need to persist between requests. At the
moment these are COM objects, but they'll be ported to Perl Classes. It
is quite important that only one of these instances exist per web
server. These instances are too large to write and read to file on every
request. So I
and read to file on every
request. So I have defined the variable as a package level variable.
I have been instantiating the variable in my handler() routine if it has
not already been instantiated. ie.
Global variables are exactly that: global. If you use
something like:
our $foo
Will the different child processes created by Apache share the same
variable? Or will each child create an additional instance?
Each child has a separate interpreter and thus a separate instance of
your global. If you need to co-ordinate data between processes, you
might want to look at
I'm working on a project that is highly configurable via environment
variables.
I'd like a way to get those environment variables into my mod_perl
processes so that the mod_perl portion of this project can be configured
the same way as the non mod_perl portions.
I know that I can use
On Fri, 24 Aug 2001, Eric Hammond wrote:
Is there any way to take the Apache::ReadConfig name space
(variables set in Perl sections) and generate plain text
Apache directives?
I don't know if there is a simple answer to this one, but the way I would
handle it is to scrap the Perl sections
, this is a
question which may be not right here !
I don`t want to use the perlmodule CGI !!
I hope some persons can help me,
primarily, global variables are looked down upon.
but like the error message says, you can explicitly name any
global like this:
$The::Meaning::Of::Life::The::Universe
Hi all,
i want to define a global variable which is also present in subroutines
coded in
extra perl modules.
I tried this our $test; but amod_perl tells me following Global
symbol $test requires explicit package name I know, this is a
question which may be not right here !
I don`t want to use
Scott Alexander ([EMAIL PROTECTED]) said something to this effect on
04/27/2001:
Should this work in a startup.pl file
my $hostname = $ENV{HOSTNAME} ;
from the prompt I can write echo $HOSTNAME and get the correct
hostname of the server.
But from within startup.pl I don't get it.
Is it possible to rewrite this perl subroutine without using variables?
sub XMLEncode {
my ($line) = @_;
$line =~ s//amp;/g;
$line =~ s//lt;/g;
$line =~ s//gt;/g;
return $line;
}
I was thinking something like
sub XMLEncode {
s//amp;/g;
s//lt;/g;
s//gt;/g
On Sun, Apr 29, 2001 at 04:34:40AM -0400, Philip Mak wrote:
I was thinking something like
sub XMLEncode {
local $_ = shift;
s//amp;/g;
s//lt;/g;
s//gt;/g;
return $_;
}
--
Honza
On Sun, 29 Apr 2001, Philip Mak wrote:
Is it possible to rewrite this perl subroutine without using variables?
sub XMLEncode {
my ($line) = @_;
$line =~ s//amp;/g;
$line =~ s//lt;/g;
$line =~ s//gt;/g;
return $line;
}
I was thinking something like
sub XMLEncode
Hi there,
On Fri, 27 Apr 2001, Philip Mak wrote:
On Fri, 27 Apr 2001, Scott Alexander wrote:
Should this work in a startup.pl file
my $hostname = $ENV{HOSTNAME} ;
from the prompt I can write echo $HOSTNAME and get the correct hostname of the
server.
But from within startup.pl I
Should this work in a startup.pl file
my $hostname = $ENV{HOSTNAME} ;
from the prompt I can write echo $HOSTNAME and get the correct
hostname of the server.
But from within startup.pl I don't get it.
Scott
On Fri, 27 Apr 2001, Scott Alexander wrote:
Should this work in a startup.pl file
my $hostname = $ENV{HOSTNAME} ;
from the prompt I can write echo $HOSTNAME and get the correct
hostname of the server.
But from within startup.pl I don't get it.
The reason echo $HOSTNAME works from the
Hello All,
I apologize if this is in a FAQ somewhere.
I have a script, lets call it test.pl. Test.pl requires in config.pl.
Test.pl uses variables (via use vars) from config.pl. These variables are
defined and given values in config.pl. AFter the first usage of test.pl,
the variables we
http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy
Guide Good!
Warren D. Johnson wrote:
Hello All,
I apologize if this is in a FAQ somewhere.
I have a script, lets call it test.pl. Test.pl requires in config.pl.
Test.pl uses variables (via use vars) from config.pl
your processes, and this
is a topic often discussed on this List. You might like to search the
archives for things like DBM, tied hash, database, shared data, shared
variables. There are links to search engines on the mod_perl home
page. Also there are one or two things in the DIGEST which might
correct but
perhaps it has forgotten all the global filled variables - what
happens.
I called the Dumper
\@ARTIKEL and he says the array is filled, but next time the array is empty -
what is my failure???
Please help
me
I am looking forward
to your answer
with
greetings
Werner
Schmidt
of bugs (witch were fixed in 5.7.0)
Best
Cb
- Original Message -
From: "Jauder Ho" [EMAIL PROTECTED]
To: "Bogomolnyi Constantin" [EMAIL PROTECTED]
Sent: Monday, March 19, 2001 8:44 AM
Subject: Re: perl5.6 (was: Shared variables, inner subs and "our")
support. 5.6.0 has a lot of bugs (witch were fixed in 5.7.0)
Best
Cb
- Original Message -
From: "Jauder Ho" [EMAIL PROTECTED]
To: "Bogomolnyi Constantin" [EMAIL PROTECTED]
Sent: Monday, March 19, 2001 8:44 AM
Subject: Re: perl5.6 (was: Shared variables, inner subs
modperl" [EMAIL PROTECTED]
Sent: Saturday, March 17, 2001 6:20 AM
Subject: Re: perl5.6 (was: Shared variables, inner subs and "our")
Stas Bekman wrote:
our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
not yet considered as a stable version for mod_perl
On Fri, 16 Mar 2001, Bogomolnyi Constantin wrote:
You should probably try 5.7.0 witch is much more stable than 5.6.0 (you
should not try unicode stuff , whitch is quite buggy)
I use 5.7.0 on all my production servers without any problems .
5.7.0 may have fixed some of the bugs of 5.6.0 but
Hi,
I was just tidying up an old mod_perl script which had some ugly "use
vars qw(...);" lines in it which I thought I'd replace with "our ...;".
I realise this isn't always a good idea since "our" is not intended as a
replacement for "use vars", but its often OK and I thought it would be
in my
not really answering your questions, but
Ragarding moving the "our()" statement out of the function --
--- Steve Hay [EMAIL PROTECTED] wrote:
(b) because I can't actually do what I just did above in my mod_perl
script!
Couldn't you, if you put the func's into a module and our()'d it
On Fri, 16 Mar 2001, Paul wrote:
not really answering your questions, but
Ragarding moving the "our()" statement out of the function --
--- Steve Hay [EMAIL PROTECTED] wrote:
(b) because I can't actually do what I just did above in my mod_perl
script!
Couldn't you, if you put the
Stas Bekman wrote:
our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
not yet considered as a stable version for mod_perl production sites,
therefore the guide barely touches on it.
Would you recommend the use of perl5.6 with mod_perl? What you are
saying is making me
On Fri, 16 Mar 2001, Wim Kerkhoff wrote:
Stas Bekman wrote:
our() and other perl5.6 new APIs are too early to be endorsed, as 5.6 is
not yet considered as a stable version for mod_perl production sites,
therefore the guide barely touches on it.
Would you recommend the use of perl5.6
gets the location of a
file from a PerlSetVar directive, and then opens the file and reads
username and password into the variables to be used for database
connection:
---
my ($dsf, $db_f_name, $db_user_name, $db_user_pwd
Anyway, what you should do is create a constructor:
sub new {
[snip]
You mean like this code segment that I included in my original post
just below the handler code :)
sub init {
[snip]
Ah yes, but you called your's "init", which is quite misleading to those of
us who tend not to
Subject: Help: Can't use string ("Exchange::Account::My") as
a HASH ref
while "strict refs" in use trying to use instance variables in my
handler
[snip]
sub handler ($$) {
my ($self, $q) = @_;
my $r= Apache::Request-new($q);
$self-child_init unless $sel
less $self-{_child_started_up};
# The rest of the code...
Then you should be good to go (instance variables and all!). Hope that
helps,
Chris
Except for calling the contructor with every call of the handler,
I think I've done everything right. Isn't the part of idea behind
mod_per
Maybe I'm missing something here, but can't you just use
use strict;
use vars qw(%config %session);
or better yet, fully qualify your variables
%MyApp::Framework::config;
%MyApp::Framework::session;
The mod_perl guide has excellent sections on this:
http://perl.apache.org/guide/perl.html
1 - 100 of 200 matches
Mail list logo
