You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Steven Scotten <st...@tourcorp.com> on 2004/06/17 02:19:57 UTC
newbie confused, documentation seems contradictory and/or incomplete.
Hello, and thanks in advance for your patience as I ask how to do
something rudimentary, but I seem to be rather dense and a week up to
my eyeballs in documentation has left me no closer than when I began.
My problem is that I'm trying to pick up mod_perl2 without ever having
used mod_perl before. I've got a ton of scripts in perl using CGI.pm,
and I don't mind doing a bit of rewriting; some of that code is very
old, and it's a good excuse to go back and clean up.
Most of what I've read suggests that what I've been doing with CGI.pm
should be replaced by Apache::Request. In fact, my module that uses
CGI.pm throws errors when included in startup.pl:
Can't locate object method "new" via package "CGI" (perhaps you
forgot to load "CGI"?)
...which it doesn't do if I leave the module out of startup.pl and just
use it in individual scripts. I have "PerlModule Apache2 CGI DBI" in my
/etc/httpd/conf.d/perl.conf file, so I don't need to use() it. I've
been led to understand that there is a performance benefit to including
frequently-used modules in my startup.pl file, and I'd like to take
advantage of that benefit.
So I've set to trying to replace CGI.pm entirely in one particular
module. It looks as though Apache::Request would have been my path in
mod_perl 1.x and I've been looking at
http://perl.apache.org/docs/2.0/user/porting/compat.html (among other
places) for what to do.
Under $r->request it says "Use Apache->request".
Under Apache->request it says "Apache->request usage should be avoided
under mod_perl 2.0 $r should be passed around as an argument instead"
...so I'm stumped.
The docs for 2.0 don't seem as complete as the docs for mod 1.0, which
makes perfect sense since 2.0 seems to still be not quite complete. But
it's pretty difficult to keep track of what from the 1.0 docs applies
to 2.0 and what doesn't. All things being equal, I'd really rather
learn the current ways than to learn the old ways and immediately
unlearn them. But I need a bit of guidance here.
My apologies, I seem to be unclear on a number of concepts here, and
it's hard to get enough reference points to form a foundation to help
me put this all together. I'll appreciate even being told what an idiot
I am, as long as I get a little closer to a clue.
My system is Fedora Core 1, Apache/2.0.49 (Magic Number: 20020903:7)
installed from RPM (httpd-2.0.49-1.1) and mod_perl-1.99_14 compiled
from tarball (it had been installed from RPM, but I read that I
shouldn't even bother asking questions on this list unless I had the
most current version, and doing an RPM ugrade to 1.99_14 from 1.99_12
broke everything, so I rpm -e'ed it and installed from tarball--it
works fine now)
Thanks again, and my apologies for not being able to formulate a more
concise question.
Steve
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or incomplete.
Posted by Stas Bekman <st...@stason.org>.
Steven Scotten wrote:
> Hello, and thanks in advance for your patience as I ask how to do
> something rudimentary, but I seem to be rather dense and a week up to my
> eyeballs in documentation has left me no closer than when I began.
>
> My problem is that I'm trying to pick up mod_perl2 without ever having
> used mod_perl before. I've got a ton of scripts in perl using CGI.pm,
> and I don't mind doing a bit of rewriting; some of that code is very
> old, and it's a good excuse to go back and clean up.
>
> Most of what I've read suggests that what I've been doing with CGI.pm
> should be replaced by Apache::Request.
Not necessarily. The two are quite close functionality-wise, but
Apache::Request is much faster as it's written in C. mod_perl 2.0 requires
Apache::Request 2.0, which is in beta now. You can get it from
http://httpd.apache.org/apreq/. Though if you are new to this area, I'd advise
to use CGI.pm at the moment and move on to Apache::Request when it's finished
(which should be pretty soon). Though do give it a try and see if it works for
you, since if people don't try it and don't report problems, it'll take longer
to get it released.
> In fact, my module that uses
> CGI.pm throws errors when included in startup.pl:
>
> Can't locate object method "new" via package "CGI" (perhaps you forgot
> to load "CGI"?)
You create new CGI objects at request time, not at the server startup.
> ...which it doesn't do if I leave the module out of startup.pl and just
> use it in individual scripts. I have "PerlModule Apache2 CGI DBI" in my
> /etc/httpd/conf.d/perl.conf file, so I don't need to use() it.
No, you still need to use() it. It's because use = require+import. Take a look at:
http://perl.apache.org/docs/1.0/guide/config.html#The_Confusion_with_use___in_the_Server_Startup_File
> I've been
> led to understand that there is a performance benefit to including
> frequently-used modules in my startup.pl file, and I'd like to take
> advantage of that benefit.
>
> So I've set to trying to replace CGI.pm entirely in one particular
> module. It looks as though Apache::Request would have been my path in
> mod_perl 1.x and I've been looking at
> http://perl.apache.org/docs/2.0/user/porting/compat.html (among other
> places) for what to do.
>
> Under $r->request it says "Use Apache->request".
>
> Under Apache->request it says "Apache->request usage should be avoided
> under mod_perl 2.0 $r should be passed around as an argument instead"
>
> ...so I'm stumped.
There is no contradiction here. Both items tell you how to move from mp1 to
mp2. recent CGI.pm versions accept $r as an argument. mentioned here:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_
Also make sure that you read:
http://perl.apache.org/docs/2.0/user/coding/coding.html#Getting_the_C__r__Object
> The docs for 2.0 don't seem as complete as the docs for mod 1.0, which
> makes perfect sense since 2.0 seems to still be not quite complete. But
> it's pretty difficult to keep track of what from the 1.0 docs applies to
> 2.0 and what doesn't. All things being equal, I'd really rather learn
> the current ways than to learn the old ways and immediately unlearn
> them. But I need a bit of guidance here.
You don't need to apologize, Steven, just ask questions and eventually the
gaps in the 2.0 will be filled out, hopefully with help from folks like
yourself. It probabaly doesn't help much, but when mp1 started there were no
docs at all, so mp2 starts in a much better shape.
What really needs to be done is for someone to take the lead on porting mp1
docs to mp2 docs. Most of those docs can be ported with very minimal changes.
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or
incomplete.
Posted by Sam Tregar <sa...@tregar.com>.
On Wed, 23 Jun 2004, Steven Scotten wrote:
> Am I clear here that you're suggesting that I scrap the idea of working
> with Apache2 and just go back to 1.3?
Yes.
> I'm concerned that six (or eighteen) months down the line if I have
> questions they'll be answered by "you should be running the most
> current version, stop pestering with obsolete Apache 1.3" Setting up
> a new server has been enough of a pain without doing it again in a
> few months.
I suppose that's possible, but I find it unlikely. Apache 1.3 is very
stable and I don't expect to see a mass shift to Apache 2 in
production usage any time soon, particularly in mod_perl programming
where the porting costs are non-zero.
Actually, considering the relative pace of Apache 2 versus Apache 1.3
development, I think you're more likely to encounter the situation you
fear with Apache 2. The chances of a major new release altering
significant functionality in Apache 1.3 is quite low.
-sam
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: bug report question
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
John Wittkoski wrote:
> The sample bug report (using t/REPORT) says to send bug reports to dev
> <at> perl.apache.org, but the web page under "Reporting Information" (at
> http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems)
> seems to indicate bugs should be sent to this list (modperl users). Is
> either ok?
modperl@ is just fine for generic issues and bugs, and the people on dev@
are here as well. if you have traced the issue, understand what is going
wrong internally, have a patch, and so on then dev@ is probably better,
though, since that's the place where the gritty internal stuff usually happens.
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] perl modules not installed with 1.99_14?
Posted by Stas Bekman <st...@stason.org>.
John Wittkoski wrote:
[...]
> Well, in desperation I reinstalled perl, updated everything to current
> using cpan, and now 1.99_14 installs as expected, so it must have been
> something with my install. Sorry about that...
Nothing to be sorry about, John :) Glad to hear it worked.
In the future help us to help you and provide us with something we can work
with. As suggested in my previous reply, a log of 'make install' could have
been helpful. But till the next time... :)
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] perl modules not installed with 1.99_14?
Posted by John Wittkoski <jo...@aol.com>.
Stas Bekman wrote on 6/24/04, 1:43 PM:
> But you already have 1.99_13 installed. Have you tried nuking it
> first?
I ran t/REPORT _after_ I had given up on installing _14 and successfully
installed _13. Sorry for the confusion.
> May be your timestamps on the previously installed
> files are in the future?
There were no previously installed files. My multiple attempts to
install _14 were prior to having any mod_perl versions installed.
(In the confusion of the multiple install attempts, I thought of this
too, but other sanity checks like 'find / -name PerlRun.pm -print' also
showed nothing had been installed.)
> What's the output of 'make install'?
> I've seen this kind of problem before with other
> perl modules. Most likely some glitch with ExtUtils::MakeMaker.
> Have you tried upgrading it?
Already up to date...
cpan> i ExtUtils::MakeMaker
Strange distribution name [ExtUtils::MakeMaker]
Module id = ExtUtils::MakeMaker
DESCRIPTION Writes Makefiles for extensions
CPAN_USERID MMML (The MakeMaker mailing list <ma...@perl.org>)
CPAN_VERSION 6.21
CPAN_FILE M/MS/MSCHWERN/ExtUtils-MakeMaker-6.21.tar.gz
DSLI_STATUS SupO (standard,comp.lang.perl.*,perl,object-oriented)
MANPAGE ExtUtils::MakeMaker - Create a module Makefile
INST_FILE /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm
INST_VERSION 6.21
Well, in desperation I reinstalled perl, updated everything to current
using cpan, and now 1.99_14 installs as expected, so it must have been
something with my install. Sorry about that...
Thanks,
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] perl modules not installed with 1.99_14?
Posted by Stas Bekman <st...@stason.org>.
John Wittkoski wrote:
>
> -------------8<---------- Start Bug Report ------------8<----------
> 1. Problem Description:
>
>
> I've tried this multiple times, always with the same result,
> and I didn't see anything in Changes that would account for
> this, so...
>
>
> This was on a machine which didn't have mod_perl (1 or 2) installed at
> all initially.
>
> When installing 1.99_14 using the standard procedure:
>
> perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
> make
> make test
> make install
>
> The modules are in blib, tests succeed and the headers are installed
> under /usr/local/apache2/include/, but none of the perl modules (APR::*,
> Apache::*, ModPerl::*etc) are installed under /usr/lib/perl5/.
>
> Initially I thought they must have been installed in some other
> location, but I used find on / didn't turn up anything. I also did a
> 'touch TIMESTAMP' before 'make install' and then 'find -newer ...',
> which showed the headers were updated but no modules.
>
> After a while I decided to try 1.99_13, and:
> Doing the exact same procedure with 1.99_13 on the same machine installs
> the modules as expected.
[...]
> *** Packages of interest status:
>
> Apache::Request: 2.02-dev
> CGI : 3.05
> LWP : 5.79
> mod_perl : 1.9913
But you already have 1.99_13 installed. Have you tried nuking it first? May be
your timestamps on the previously installed files are in the future? What's
the output of 'make install'? I've seen this kind of problem before with other
perl modules. Most likely some glitch with ExtUtils::MakeMaker. Have you tried
upgrading it?
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] perl modules not installed with 1.99_14?
Posted by John Wittkoski <jo...@aol.com>.
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
I've tried this multiple times, always with the same result,
and I didn't see anything in Changes that would account for
this, so...
This was on a machine which didn't have mod_perl (1 or 2) installed at
all initially.
When installing 1.99_14 using the standard procedure:
perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
make
make test
make install
The modules are in blib, tests succeed and the headers are installed
under /usr/local/apache2/include/, but none of the perl modules (APR::*,
Apache::*, ModPerl::*etc) are installed under /usr/lib/perl5/.
Initially I thought they must have been installed in some other
location, but I used find on / didn't turn up anything. I also did a
'touch TIMESTAMP' before 'make install' and then 'find -newer ...',
which showed the headers were updated but no modules.
After a while I decided to try 1.99_13, and:
Doing the exact same procedure with 1.99_13 on the same machine installs
the modules as expected.
2. Used Components and their Configuration:
*** mod_perl version 1.9914
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /usr/local/apache2
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /usr/local/apache2/bin/httpd -V
Server version: Apache/2.0.49
Server built: Jun 5 2004 22:50:19
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/usr/local/apache2"
-D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-1.1931.2.382.entsmp,
archname=i386-linux-thread-multi
uname='linux stripples.devel.redhat.com 2.4.21-1.1931.2.382.entsmp
#1 smp wed aug 6 17:18:52 edt 2003 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
-Dvendorprefix=/usr -Dsiteprefix=/usr
-Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
-Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less
-isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
MAINT18379
Built under linux
Compiled at Aug 13 2003 11:47:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
*** Packages of interest status:
Apache::Request: 2.02-dev
CGI : 3.05
LWP : 5.79
mod_perl : 1.9913
3. This is the core dump trace: (if you get a core dump):
No core
This report was generated by t/REPORT on Wed Jun 23 14:55:18 2004 GMT.
-------------8<---------- End Bug Report --------------8<----------
Note: Complete the rest of the details and post this bug report to
dev <at> perl.apache.org. To subscribe to the list send an empty
email to dev-subscribe@perl.apache.org.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
bug report question
Posted by John Wittkoski <jo...@aol.com>.
The sample bug report (using t/REPORT) says to send bug reports to dev
<at> perl.apache.org, but the web page under "Reporting Information" (at
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems)
seems to indicate bugs should be sent to this list (modperl users). Is
either ok?
--John
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or incomplete.
Posted by Steven Scotten <st...@tourcorp.com>.
On Jun 17, 2004, at 9:25 PM, Sam Tregar wrote:
> On Wed, 16 Jun 2004, Steven Scotten wrote:
>
>> My problem is that I'm trying to pick up mod_perl2 without ever having
>> used mod_perl before.
>
> I agree. I think you should back up a step and get comfortable with
> mod_perl 1. Unless you're doing this just for the thrill of learning
> something new and difficult I think you'll get better results faster
> from mod_perl 1.
Sorry for taking so long to reply, I'm trying to follow-through and
research all the suggestions, and I've been given a lot to work with.
Am I clear here that you're suggesting that I scrap the idea of working
with Apache2 and just go back to 1.3? I'm concerned that six (or
eighteen) months down the line if I have questions they'll be answered
by "you should be running the most current version, stop pestering with
obsolete Apache 1.3" Setting up a new server has been enough of a pain
without doing it again in a few months.
I'm moving from a shared server to a dedicated hosting box, which means
I just got *ahem* promoted from developer to system administrator. My
sysadmin friends have a saying: beware a programmer carrying a
screwdriver. Unfortunately I'm not even that much of a programmer but
I'm all I've got here.
Steve
--
Steven M. Scotten, Project (mis)Manager, TourCorp Inc.
<st...@tourcorp.com>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or
incomplete.
Posted by Sam Tregar <sa...@tregar.com>.
On Wed, 16 Jun 2004, Steven Scotten wrote:
> My problem is that I'm trying to pick up mod_perl2 without ever having
> used mod_perl before.
I agree. I think you should back up a step and get comfortable with
mod_perl 1. Unless you're doing this just for the thrill of learning
something new and difficult I think you'll get better results faster
from mod_perl 1.
-sam
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or incomplete.
Posted by Glenn <gs...@gluelogic.com>.
On Wed, Jun 16, 2004 at 05:19:57PM -0700, Steven Scotten wrote:
> Hello, and thanks in advance for your patience as I ask how to do
> something rudimentary, but I seem to be rather dense and a week up to
> my eyeballs in documentation has left me no closer than when I began.
No apology necessary. It's quite clear that you've made an effort,
and that effort is greatly appreciated.
> Most of what I've read suggests that what I've been doing with CGI.pm
> should be replaced by Apache::Request. In fact, my module that uses
> CGI.pm throws errors when included in startup.pl:
>
> Can't locate object method "new" via package "CGI" (perhaps you
> forgot to load "CGI"?)
use CGI();
CGI->compile();
For more information, 'perldoc CGI' and scroll down to where the
"-compile" switch is explained.
That should get rid of that error. However, as you already know,
Apache::Request is preferred over CGI.pm in mod_perl for both
performance (Apache::Request is part of the Apache API and
written in C) and resource usage (CGI.pm takes a lot more
memory).
Now, please realize that there are _numerous_ ways to have modperl
run your module. ModPerl::Registry is one of them. Writing an
actual "handler", in the vernacular of the Apache API, is another,
and those are not the only ways.
Also, modperl is not limited to producing content. It can do all
sorts of other neat configuration, authentication, and more cool
stuff in Apache. But that's a bedtime story for another day.
> So I've set to trying to replace CGI.pm entirely in one particular
> module. It looks as though Apache::Request would have been my path in
> mod_perl 1.x and I've been looking at
> http://perl.apache.org/docs/2.0/user/porting/compat.html (among other
> places) for what to do.
>
> Under $r->request it says "Use Apache->request".
$r is generally where the request object is stored.
(Whenever you see $r in the documentation, it refers to the current
request object.)
To use Apache::Request instead of CGI.pm, replace
use CGI;
$q = new CGI;
with:
use Apache::Request ();
my $q = Apache::Request->new($r);
and see
http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_use_Apache_Perl_Modules
Now, you don't _have_ to replace CGI.pm.
Apache::Request is just another way to do things.
If writing a handler, which is yet another way to run code in modperl,
the request object will be passed to you as a param.
sub handler {
my $r = shift;
# my main routine code
example_subroutine($r,$_and,$other,$params);
return Apache::Constants::OK;
}
sub example_subroutine {
my($r,$_and,$other,$params) = @_;
# other code
}
As shown above, for subroutines, pass $r as a parameter to
pass the request object between your routines.
If you fall into a situation where it is gross or obtuse to
pass $r as a parameter down through some chains, then in the
deeply nested subroutine, you can actually get $r by doing
sub deeply_nested_routine {
$r = Apache->request;
}
Or, you can do something like:
use vars qw($r);
sub handler {
## always local()ize global variables in modperl! (well, almost always)
local $r = shift;
# ...
return Apache::Constants::OK;
}
sub deeply_nested_routine {
# $r is a global variable that has been localized
# We already have access to use it in this routine.
my $uri = $r->uri;
}
TIMTOWTDI.
Once you have $r, you have easy access to a whole lot of information
and request parameters. 'perldoc Apache' or perldoc 'ModPerl' (I think)
for more information.
Hope I haven't confused you more by giving you so many options.
Cheers,
Glenn
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::Registry HostNameWithVirtualHost
Posted by Stas Bekman <st...@stason.org>.
Peter N Lewis wrote:
> Hi all,
>
> I ran in to a problem using NameWithVirtualHost because I used Rewrite
> rules based on the host name inside a single virtual host and so ended
> up with, in my case:
>
> http://www.interarchy.com/main/index.pl
> and
> http://www.stairways.com/main/index.pl
>
> going to different files in the file system, but both in the same
> virtual host (because they share most of the site, only the main entry
> is different).
>
> Anyway, the Apache::Registry bases the cache/Package name on the virtual
> host name and the path of the URL. I don't really know why it isn't
> based on the full disk pathname, but anyway, this wasn't sufficient for
> my purposes, so I added support for using the hostname instead of the
> virtual server name:
>
> --- Registry.pm.orig Tue Jun 15 20:55:32 2004
> +++ Registry.pm Wed Jun 16 21:02:38 2004
> @@ -20,6 +20,9 @@
> unless (defined $Apache::Registry::NameWithVirtualHost) {
> $Apache::Registry::NameWithVirtualHost = 1;
> }
> +unless (defined $Apache::Registry::HostNameWithVirtualHost) {
> + $Apache::Registry::HostNameWithVirtualHost = 0;
> +}
> unless (defined $Apache::Registry::MarkLine) {
> $Apache::Registry::MarkLine = 1;
> }
> @@ -75,7 +78,10 @@
>
> $script_name =~ s:/+$:/__INDEX__:;
>
> - if ($Apache::Registry::NameWithVirtualHost &&
> $r->server->is_virtual) {
> + if ($Apache::Registry::HostNameWithVirtualHost &&
> $r->server->is_virtual) {
> + my $name = $r->hostname;
> + $script_name = join "", $name, $script_name if $name;
> + } elsif ($Apache::Registry::NameWithVirtualHost &&
> $r->server->is_virtual) {
> my $name = $r->get_server_name;
> $script_name = join "", $name, $script_name if $name;
> }
>
> This is for mod_perl 1.0. I saw that mod_perl 2.0 does things slightly
> differently, but essentially has this same functionality. Anyway, I'm
> sending this to for consideration. The downside of by-host is that
> hosts like www.interarchy.com and interarchy.com would be treated
> differently. The upside is it works even in the case I've got. It'd be
> nice not to have to patch mod_perl with each install I do, so if this
> might be generally useful then perhaps it could be incorporated.
If using the full pathname works, there is no point adding extra
functionality, which as you yourself mentioned above is not quite perfect. I
can't remember now why the full pathname wasn't used, you can find the reason
in the maillist archives. But it had something to do with not working on
certain setups.
The solution is use a subclass of Apache::RegistryNG or Apache::PerlRun, which
uses the filepath for the cache. I think the archives has the code that does
that. It's about time someone released that subclass on CPAN.
As for mp2, it already uses the full filepath by default and provides a method
that you can use to use the mp1-like uri based cache entry.
From: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
#########################################################################
# func: namespace_from
# dflt: namespace_from_filename
# desc: returns a partial raw package name based on filename, uri, else
# args: $self - registry blessed object
# rtrn: a unique string
#########################################################################
*namespace_from = \&namespace_from_filename;
# return a package name based on $r->filename only
sub namespace_from_filename {
my $self = shift;
my ($volume, $dirs, $file) =
File::Spec::Functions::splitpath($self->{FILENAME});
my @dirs = File::Spec::Functions::splitdir($dirs);
return join '_', grep { defined && length } $volume, @dirs, $file;
}
# return a package name based on $r->uri only
sub namespace_from_uri {
my $self = shift;
my $path_info = $self->{REQ}->path_info;
my $script_name = $path_info && $self->{URI} =~ /$path_info$/
? substr($self->{URI}, 0, length($self->{URI}) - length($path_info))
: $self->{URI};
if ($ModPerl::RegistryCooker::NameWithVirtualHost &&
$self->{REQ}->server->is_virtual) {
my $name = $self->{REQ}->get_server_name;
$script_name = join "", $name, $script_name if $name;
}
$script_name =~ s:/+$:/__INDEX__:;
return $script_name;
}
--
__________________________________________________________________
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache::Registry HostNameWithVirtualHost
Posted by Peter N Lewis <pe...@stairways.com.au>.
Hi all,
I ran in to a problem using NameWithVirtualHost because I used
Rewrite rules based on the host name inside a single virtual host and
so ended up with, in my case:
http://www.interarchy.com/main/index.pl
and
http://www.stairways.com/main/index.pl
going to different files in the file system, but both in the same
virtual host (because they share most of the site, only the main
entry is different).
Anyway, the Apache::Registry bases the cache/Package name on the
virtual host name and the path of the URL. I don't really know why
it isn't based on the full disk pathname, but anyway, this wasn't
sufficient for my purposes, so I added support for using the hostname
instead of the virtual server name:
--- Registry.pm.orig Tue Jun 15 20:55:32 2004
+++ Registry.pm Wed Jun 16 21:02:38 2004
@@ -20,6 +20,9 @@
unless (defined $Apache::Registry::NameWithVirtualHost) {
$Apache::Registry::NameWithVirtualHost = 1;
}
+unless (defined $Apache::Registry::HostNameWithVirtualHost) {
+ $Apache::Registry::HostNameWithVirtualHost = 0;
+}
unless (defined $Apache::Registry::MarkLine) {
$Apache::Registry::MarkLine = 1;
}
@@ -75,7 +78,10 @@
$script_name =~ s:/+$:/__INDEX__:;
- if ($Apache::Registry::NameWithVirtualHost && $r->server->is_virtual) {
+ if ($Apache::Registry::HostNameWithVirtualHost &&
$r->server->is_virtual) {
+ my $name = $r->hostname;
+ $script_name = join "", $name, $script_name if $name;
+ } elsif ($Apache::Registry::NameWithVirtualHost &&
$r->server->is_virtual) {
my $name = $r->get_server_name;
$script_name = join "", $name, $script_name if $name;
}
This is for mod_perl 1.0. I saw that mod_perl 2.0 does things
slightly differently, but essentially has this same functionality.
Anyway, I'm sending this to for consideration. The downside of
by-host is that hosts like www.interarchy.com and interarchy.com
would be treated differently. The upside is it works even in the
case I've got. It'd be nice not to have to patch mod_perl with each
install I do, so if this might be generally useful then perhaps it
could be incorporated.
Thanks for your time,
Peter.
--
I will be away until June 20, and then again from June 26-July 6.
<http://www.interarchy.com/> <http://download.interarchy.com/>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: newbie confused, documentation seems contradictory and/or
incomplete.
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2004-06-16 at 20:19, Steven Scotten wrote:
> So I've set to trying to replace CGI.pm entirely in one particular
> module. It looks as though Apache::Request would have been my path in
> mod_perl 1.x and I've been looking at
> http://perl.apache.org/docs/2.0/user/porting/compat.html (among other
> places) for what to do.
>
> Under $r->request it says "Use Apache->request".
Just in case it wasn't clear, Apache::Request and Apache->request() are
totally different things. Apache::Request is a module provided by the
libapreq distribution, which is used for parsing query arguments.
Apache->request is a way to get the current request object, usually
referred to as $r. It is used for all kinds of things related to the
current request. To make an Apache::Request object, you give it an
Apache->request() object which it uses to access the query string and
other input. Confusing, but it's important to understand the
difference.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html