You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/04/11 05:18:18 UTC
a new API proposal for passing $r to CGI.pm/CGI::Cookie
Hi Lincoln,
Nick Tonkin is working on the patch to make CGI::Cookie work properly under
modperl 2.0 in pre-response handlers, and the issue of providing the API for
passing $r to CGI.pm and CGI::Cookie has been raised again.
I'm proposing the following API:
- CGI.pm:
CGI->r($r); # for non-OO API
or
my $q = CGI->new;
$q->r($r); # for OO API
- CGI::Cookie
CGI::Cookie::r($r);
or something like that. Though we have to make into an account that CGI.pm
might be used in sub-requests, so we should probably make sure that we aren't
using the wrong global $r.
and this is the implementation for CGI::Cookie (we need a similar one for
CGI.pm). I have also suggested to abstract all the mp functionality in a
separate module e.g., CGI/MP.pm, so we don't have to duplicate and maintain
several copies of the same code. Loading CGI.pm in CGI::Cookie sounds like a
bad idea if CGI is not already used elsewhere, because of the bloat.
package CGI::Cookie;
...
use vars qw($gr); # global $r
# get/set
sub r {
$gr = shift if @_;
return $gr || Apache->request;
}
sub new {
...
if ($MOD_PERL) {
r()->pool->cleanup_register(\&CGI::Cookie::_reset_globals);
}
}
sub _reset_globals { initialize_globals(); }
sub initialize_globals {
$gr = undef;
}
__________________________________________________________________
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
Re: beta12
Posted by Lincoln Stein <ls...@cshl.org>.
OK, got it.
Lincoln
On Monday 21 April 2003 12:35 am, Stas Bekman wrote:
> + if ($MOD_PERL && !exists $ENV{REQUEST_METHOD}) {
> + die "Run $r->subprocess_env; before calling fetch()";
> + }
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: beta12
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> Stas's patch didn't go in cleanly, so I fiddled with it a bit.
Beta12 looks good. One last bit, for CGI/Cookie.pm
--- CGI/Cookie.pm.orig 2003-04-21 14:18:51.000000000 +1000
+++ CGI/Cookie.pm 2003-04-21 14:25:41.000000000 +1000
@@ -75,6 +75,9 @@
if ($r) {
$raw_cookie = $r->headers_in->{'Cookie'};
} else {
+ if ($MOD_PERL && !exists $ENV{REQUEST_METHOD}) {
+ die "Run $r->subprocess_env; before calling fetch()";
+ }
$raw_cookie = $ENV{HTTP_COOKIE} || $ENV{COOKIE};
}
}
this is needed for pre-response handlers which haven't passed $r arg. If $r is
not available and $r->subprocess_env wasn't run CGI::Cookie will silently fail
to fetch the cookie. Apache->request is not available before the response
phase, however can be made available by calling Apache->request($r).
So there are three ways to get the cookie in pre-response handlers under mp2:
fetch($r);
$r->subprocess_env();
fetch();
Apache->request($r)
fetch();
__________________________________________________________________
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
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> So I don't have mp2 installed and can't directly test any of this. I know
> it's working ok on mp1.
>
> The section in question was submitted by Stas. I hope I haven't broken it.
> We're not doing the reading from the headers yet because I have to tear the
> guts out of CGI.pm and stick all the places that get headers into separate
> .pm modules that are loaded alternately as needed by the mp1, mp2 and CGI
> environments.
Well it was really a work on different things at the same time. If Lincoln is
anxious to get this version out, the current version (+patches, see below)
seems to be good enough functionality wise. What's important at this stage is
to get CGI.pm working with mp2 for all phases. Once this CGI.pm version is
released we can do another round of improvements where we eliminate the use of
subprocess_env completely and rely on $r->headers_in everywhere (under mod_perl).
> I was really hoping to get this version of CGI.pm out the door this week,
> because there are a number of bug fixes in addition to the mod_perl changes.
> If this isn't working, I'm going to backtrack on the mp2 fixes and leave them
> for some other time.
Please keep the current changes in, plus apply this patch (against
CGI.pm-2.92b9.tar.gz, which doesn't work under mp2). I've tested it with mp1
and mp2.
--- CGI.pm.orig 2003-04-18 11:43:45.000000000 +1000
+++ CGI.pm 2003-04-18 12:04:10.000000000 +1000
@@ -304,8 +304,8 @@
)) {
$self->r(shift @initializer);
}
- if (my $r = ($self->r || $MOD_PERL)) {
- $self->r($r) unless $self->r;
+ if ($MOD_PERL) {
+ my $r = $self->r;
if ($MOD_PERL == 1) {
$r->register_cleanup(\&CGI::_reset_globals);
}
@@ -328,9 +328,9 @@
sub r {
my $self = shift;
- my $r = $self->{'.r'};
$self->{'.r'} = shift if @_;
- $r;
+ $self->{'.r'} ||= Apache->request;
+ $self->{'.r'};
}
#### Method: param
@@ -500,7 +500,7 @@
# the environment.
if ($meth=~/^(GET|HEAD)$/) {
if ($MOD_PERL) {
- $query_string = Apache->request->args;
+ $query_string = $self->r->args;
} else {
$query_string = $ENV{'QUERY_STRING'} if defined $ENV{'QUERY_STRING'};
$query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
@@ -1349,7 +1349,7 @@
push(@header,"Content-Type: $type") if $type ne '';
my $header = join($CRLF,@header)."${CRLF}${CRLF}";
if ($MOD_PERL and not $nph) {
- Apache->request->send_cgi_header($header);
+ $self->r->send_cgi_header($header);
return '';
}
return $header;
Also a tiny doc patch:
--- CGI/Cookie.pm.orig 2003-04-18 11:56:49.000000000 +1000
+++ CGI/Cookie.pm 2003-04-18 11:56:55.000000000 +1000
@@ -355,7 +355,7 @@
Mod_perl users can set cookies using the request object's header_out()
method:
- $r->header_out('Set-Cookie',$c);
+ $r->headers_out->set('Set-Cookie' => $c);
Internally, Cookie overloads the "" operator to call its as_string()
method when incorporated into the HTTP header. as_string() turns the
and probably need to document the newly added fetch($r).
Thanks.
__________________________________________________________________
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
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Lincoln Stein <ls...@cshl.org>.
So I don't have mp2 installed and can't directly test any of this. I know
it's working ok on mp1.
The section in question was submitted by Stas. I hope I haven't broken it.
We're not doing the reading from the headers yet because I have to tear the
guts out of CGI.pm and stick all the places that get headers into separate
.pm modules that are loaded alternately as needed by the mp1, mp2 and CGI
environments.
I was really hoping to get this version of CGI.pm out the door this week,
because there are a number of bug fixes in addition to the mod_perl changes.
If this isn't working, I'm going to backtrack on the mp2 fixes and leave them
for some other time.
Lincoln
On Thursday 17 April 2003 03:23 pm, Nick Tonkin wrote:
> On Thu, 17 Apr 2003, Lincoln Stein wrote:
> > Sorry, beta9 didn't include Nick's patches. I had to modify the patch
> > slightly in order to keep CGI::Cookie running in command-line mode, since
> > various people use CGI::Cookie outside the web server environment in
> > order to prepare as-is documents that are served from databases.
> >
> > Here is beta10.
>
> This version of CGI threw an error for me:
>
> Can't call method "pool" without a package or object reference at
> /home/debug/perl/lib/5.8.0/CGI.pm line 316.
>
> I'm afraid the call is not likely to shed much light:
>
> my $q = new CGI;
>
> Also, if I am reading the code correctly, I do not understand
> why I'm in that block anyway. Shouldn't $MOD_PERL be true?
>
> Also also, if I am reading the code properly, it looks like you
> call $r->subprocess_env if the ENV is not set up. I thought we
> were going to use the headers instead?
>
> Thanks,
>
>
>
> - nick
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Thu, 17 Apr 2003, Lincoln Stein wrote:
> Sorry, beta9 didn't include Nick's patches. I had to modify the patch
> slightly in order to keep CGI::Cookie running in command-line mode, since
> various people use CGI::Cookie outside the web server environment in order to
> prepare as-is documents that are served from databases.
>
> Here is beta10.
This version of CGI threw an error for me:
Can't call method "pool" without a package or object reference at /home/debug/perl/lib/5.8.0/CGI.pm line 316.
I'm afraid the call is not likely to shed much light:
my $q = new CGI;
Also, if I am reading the code correctly, I do not understand
why I'm in that block anyway. Shouldn't $MOD_PERL be true?
Also also, if I am reading the code properly, it looks like you
call $r->subprocess_env if the ENV is not set up. I thought we
were going to use the headers instead?
Thanks,
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> Here is beta9.
beta9? I was testing beta10 before... what has happened to the b10?
__________________________________________________________________
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
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Wed, 16 Apr 2003, Stas Bekman wrote:
> Nick, it looks like a good time to plug your CGI::Cookie patch in.
Lincoln,
The attached patch makes CGI::Cookie work with mod_perl 2. The ENV hash is not
available prior to the response stage of the request in mp2 so many applications
that use cookies prior to that stage (for example, in access or auth handlers) were
unable to read them with CGI::Cookie.
The patch checks to see what version of mod_perl is running and retrieves the cookies
from the headers if available.
Enjoy,
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Stas Bekman <st...@stason.org>.
Nick Tonkin wrote:
> On Wed, 16 Apr 2003, Stas Bekman wrote:
>
>
>>Finally CGI::Cookie uses $r->header_in, which is deprecated in mp1 and doesn't
>>exists in mp2. It should be $r->headers_in->get('Cookie'), or at least do that
>>for mp2.
>
>
> I just noticed this ... I've been using $r->headers_in->{'Cookie'} (which works
> fine apparently) ... is there a problem with that and should I change the patch
> I made so it uses the method call instead?
I haven't benchmarked the difference, but I think that get() (the function
interface) would be a tiny bit faster than the TIE interface, since the latter
calls the same function underneath, after calling FETCH on the object.
FWIW, Apache::Table is supported by mod_perl since mod_perl 1.16_01 (1998)
according to the Changes file.
> I do not believe the method call syntax is documented anywhere for mp2,
It is:
http://perl.apache.org/docs/2.0/api/APR/Table.html
Need to add docs for headers_in and others... patches are welcome (should be
easy to port from 1.0 docs).
> and the mp1
> docs don't refer to it at http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_headers_in
It documents that the returned object is an Apache::Table object.
which is documented here: http://perl.apache.org/docs/1.0/api/Apache/Table.html
Feel free to submit a patch that xrefs the two.
__________________________________________________________________
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
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Wed, 16 Apr 2003, Stas Bekman wrote:
> Finally CGI::Cookie uses $r->header_in, which is deprecated in mp1 and doesn't
> exists in mp2. It should be $r->headers_in->get('Cookie'), or at least do that
> for mp2.
I just noticed this ... I've been using $r->headers_in->{'Cookie'} (which works
fine apparently) ... is there a problem with that and should I change the patch
I made so it uses the method call instead?
I do not believe the method call syntax is documented anywhere for mp2, and the mp1
docs don't refer to it at http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_headers_in
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Wed, 16 Apr 2003, Stas Bekman wrote:
> Lincoln Stein wrote:
> > I've implemented the ability to pass $r to CGI and CGI::Cookie on
> > initialization. This should make it easier to use CGI in earlier phases of
> > the request cycle. It works for me, but please try it.
>
> I've just read the diff, hadn't tried it yet. It looks good, but there are
> several things that need more work. In mod_perl 2, ref($r) returns
> 'Apache::RequestRec' so it should be:
>
> ... && ($r->isa('Apache') || $r->isa('Apache::RequestRec'))
>
> in both modules. or have the logic different depending on the value of $MOD_PERL.
>
> The addition of the r() API is probably worthy an entry in the Changes log.
>
> Also why using Apache->request($r) for the functional API and not CGI::r()? We
> should stay way from using Apache->request if possible, because this requires
> storing/retrieving data from the thread-local storage in the threaded
> environment. The functional interface is already maintaining a set of global
> vars, so there shouldn't be a problem adding a new global.
>
> Finally CGI::Cookie uses $r->header_in, which is deprecated in mp1 and doesn't
> exists in mp2. It should be $r->headers_in->get('Cookie'), or at least do that
> for mp2.
>
> Nick, it looks like a good time to plug your CGI::Cookie patch in.
Alright. Where should I send it? Lincoln, do you want it?
>
> Since now we make sure that we have $r for both mod_perl generations, the next
> stage for CGI.pm to stop relying on %ENV and use $r->headers_in interface to
> get the required request header values.
>
> __________________________________________________________________
> 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
>
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> I've implemented the ability to pass $r to CGI and CGI::Cookie on
> initialization. This should make it easier to use CGI in earlier phases of
> the request cycle. It works for me, but please try it.
I've just read the diff, hadn't tried it yet. It looks good, but there are
several things that need more work. In mod_perl 2, ref($r) returns
'Apache::RequestRec' so it should be:
... && ($r->isa('Apache') || $r->isa('Apache::RequestRec'))
in both modules. or have the logic different depending on the value of $MOD_PERL.
The addition of the r() API is probably worthy an entry in the Changes log.
Also why using Apache->request($r) for the functional API and not CGI::r()? We
should stay way from using Apache->request if possible, because this requires
storing/retrieving data from the thread-local storage in the threaded
environment. The functional interface is already maintaining a set of global
vars, so there shouldn't be a problem adding a new global.
Finally CGI::Cookie uses $r->header_in, which is deprecated in mp1 and doesn't
exists in mp2. It should be $r->headers_in->get('Cookie'), or at least do that
for mp2.
Nick, it looks like a good time to plug your CGI::Cookie patch in.
Since now we make sure that we have $r for both mod_perl generations, the next
stage for CGI.pm to stop relying on %ENV and use $r->headers_in interface to
get the required request header values.
__________________________________________________________________
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
Re: CGI::Carp
Posted by Lincoln Stein <ls...@cshl.org>.
There are two uses of CGI::Carp:
1) place time-stamped entries in the httpd error log (rather than unstamped
entries by default)
2) send fatal errors -- including compile time errors! -- to the browser
What I'll do is to distinguish between these two uses and only override
$SIG{__DIE__} when the user has requested behavior (2).
Lincoln
On Sunday 11 May 2003 09:21 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> > Sorry, but even when placed in a BEGIN {} block, CORE::GLOBAL::die won't
> > catch compile-time errors the way that $SIG{__DIE__} does.
> >
> > Do you have a workaround? Otherwise I'm going to go back to using the
> > %SIG magic in CGI::Carp.
> >
> > Here's my test script:
> >
> > #!/usr/bin/perl
> >
> > BEGIN {
> > *CORE::GLOBAL::die = \&mydie;
> > }
> > foo bar baz;
> > print STDERR "VERSION = $]\n"; print STDERR "line 1\n";
> > die "dieing here\n";
> > print STDERR "line 2\n";
> > sub mydie {
> > print STDERR "In die handler\n";
> > CORE::die $@;
> > }
> >
> > Its output is
> >
> > Can't locate object method "foo" via package "bar" (perhaps you forgot
> > to load "bar"?) at foo.pl line 6.
> >
> > When I replace the BEGIN block with $SIG{__DIE__}=\&mydie, i get:
> >
> > In die handler
> > Died at foo.pl line 11.
>
> Indeed. *CORE::GLOBAL::die = \&mydie; overrides calls to die(), when it's
> explicitly called. It doesn't provide a replacement for situations where
> perl dies elsewhere. A call to:
>
> foo bar baz
>
> calls Perl_vcroak, which sees no PL_diehook ($SIG{__DIE__}) defined,
> neither it's executed in the eval {} block, so it writes the error message
> to the console and exits.
>
> Perhaps you want to execute this code in the eval block? Then it'll work as
> expected:
>
> #!/usr/bin/perl
>
> BEGIN {
> *CORE::GLOBAL::die = sub {
> print STDERR "In die handler\n";
> CORE::die $@;
> }
> }
>
> eval { foo bar baz; };
> die $@ if $@;
>
> print STDERR "VERSION = $]\n"; print STDERR "line 1\n";
> die "dieing here\n";
> print STDERR "line 2\n";
>
> Otherwise using $SIG{__DIE__} is the only catch-all way to do that. Though
> if you do that, you have to make sure to respect $^S flag/ using caller()
> as explained here:
> http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Alte
>rnative_Exception_Handling_Techniques
>
> __________________________________________________________________
> 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
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: CGI::Carp
Posted by Jarkko Hietaniemi <jh...@iki.fi>.
I suggest throwing the dilemma at the perl5-porters, they if anyone
should know what will work with various Perl versions.
--
Jarkko Hietaniemi <jh...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: CGI::Carp
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> Sorry, but even when placed in a BEGIN {} block, CORE::GLOBAL::die won't catch
> compile-time errors the way that $SIG{__DIE__} does.
>
> Do you have a workaround? Otherwise I'm going to go back to using the %SIG
> magic in CGI::Carp.
>
> Here's my test script:
>
> #!/usr/bin/perl
>
> BEGIN {
> *CORE::GLOBAL::die = \&mydie;
> }
> foo bar baz;
> print STDERR "VERSION = $]\n"; print STDERR "line 1\n";
> die "dieing here\n";
> print STDERR "line 2\n";
> sub mydie {
> print STDERR "In die handler\n";
> CORE::die $@;
> }
>
> Its output is
>
> Can't locate object method "foo" via package "bar" (perhaps you forgot to
> load "bar"?) at foo.pl line 6.
>
> When I replace the BEGIN block with $SIG{__DIE__}=\&mydie, i get:
>
> In die handler
> Died at foo.pl line 11.
Indeed. *CORE::GLOBAL::die = \&mydie; overrides calls to die(), when it's
explicitly called. It doesn't provide a replacement for situations where perl
dies elsewhere. A call to:
foo bar baz
calls Perl_vcroak, which sees no PL_diehook ($SIG{__DIE__}) defined, neither
it's executed in the eval {} block, so it writes the error message to the
console and exits.
Perhaps you want to execute this code in the eval block? Then it'll work as
expected:
#!/usr/bin/perl
BEGIN {
*CORE::GLOBAL::die = sub {
print STDERR "In die handler\n";
CORE::die $@;
}
}
eval { foo bar baz; };
die $@ if $@;
print STDERR "VERSION = $]\n"; print STDERR "line 1\n";
die "dieing here\n";
print STDERR "line 2\n";
Otherwise using $SIG{__DIE__} is the only catch-all way to do that. Though if
you do that, you have to make sure to respect $^S flag/ using caller() as
explained here:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Alternative_Exception_Handling_Techniques
__________________________________________________________________
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
Re: CGI::Carp
Posted by Lincoln Stein <ls...@cshl.org>.
Sorry, but even when placed in a BEGIN {} block, CORE::GLOBAL::die won't catch
compile-time errors the way that $SIG{__DIE__} does.
Do you have a workaround? Otherwise I'm going to go back to using the %SIG
magic in CGI::Carp.
Here's my test script:
#!/usr/bin/perl
BEGIN {
*CORE::GLOBAL::die = \&mydie;
}
foo bar baz;
print STDERR "VERSION = $]\n"; print STDERR "line 1\n";
die "dieing here\n";
print STDERR "line 2\n";
sub mydie {
print STDERR "In die handler\n";
CORE::die $@;
}
Its output is
Can't locate object method "foo" via package "bar" (perhaps you forgot to
load "bar"?) at foo.pl line 6.
When I replace the BEGIN block with $SIG{__DIE__}=\&mydie, i get:
In die handler
Died at foo.pl line 11.
Best,
Lincoln
On Sunday 11 May 2003 07:45 pm, Stas Bekman wrote:
> Daisuke Maki wrote:
> > It seems to me that CORE::GLOBAL::* can only be overridden at compile
> > time? I just did a quick test:
> >
> > BEGIN{ *CORE::GLOBAL::die = sub { print "foo" } }
> > die "bar";
> >
> > against
> >
> > *CORE::GLOBAL::die = sub { print "foo" };
> > die "bar";
> >
> > and only the one with the begin block seems to work for me, in both
> > perl5.6.1 and perl5.8.0.
>
> even with 5.005_03:
>
> /tmp> perl-5.6.1 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; }
> die "bar";'
> foo
> /tmp> perl-5.6.0 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; }
> die "bar";'
> foo
> /tmp> perl-5.00503 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; }
> die "bar";'
> foo
>
> > Lincoln Stein wrote:
> >> The fact is that this:
> >>
> >> *CORE::GLOBAL::die = \&mydie;
> >>
> >> Does not work with 5.6.0 or 5.6.1 and I am getting bug reports
> >> regarding CGI::Carp. Here is a test script:
> >>
> >> #!/usr/bin/perl
> >> use strict; *CORE::GLOBAL::die = \&mydie;
> >> print STDERR "VERSION = $]\n"; print STDERR "line 1\n"; die "dieing
> >> here\n"; print STDERR "line 2\n";
> >> sub mydie { print STDERR "In die handler\n"; die $@; }
> >> When I run it, I get:
> >>
> >> VERSION = 5.006 line 1 dieing here
> >> Rather than the expected "In die handler" message.
> >>
> >> Please tell me what I am doing wrong.
> >>
> >> Lincoln
> >>
> >> On Monday 05 May 2003 04:44 pm, Jarkko Hietaniemi wrote:
> >>>> CGI::Carp is no longer working consistently for all combinations of
> >>>> Perl and mod_perl versions. One way I have found to solve most of
> >>>> the problems people are reporting is to backtrack and go back to
> >>>> replacing the die handler this way:
> >>>>
> >>>> $SIG{__DIE__} = \&mydie;
> >>>>
> >>>> rather than
> >>>>
> >>>> *CORE::GLOBAL::die =&mydie;
> >>>>
> >>>> as is currently the case.
> >>>>
> >>>> The mailing lists are very confused (and confusing) on the issue of
> >>>> the magic $SIG{__DIE__} data structure. Can you offer any advice?
> >>>
> >>> What seems to be the, umm, confusion? Reading perlfunc and perlvar
> >>> on the subject I would say that $SIG{__DIE__} should *not* be used
> >>> currently if one wants to write a 'handler' for die(). The problem
> >>> is that the $SIG{__DIE__} is called also in evals.
--
Lincoln Stein
lstein@cshl.org
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
(516) 367-8380 (voice)
(516) 367-8389 (fax)
Re: CGI::Carp
Posted by Stas Bekman <st...@stason.org>.
Daisuke Maki wrote:
> It seems to me that CORE::GLOBAL::* can only be overridden at compile
> time? I just did a quick test:
>
> BEGIN{ *CORE::GLOBAL::die = sub { print "foo" } }
> die "bar";
>
> against
>
> *CORE::GLOBAL::die = sub { print "foo" };
> die "bar";
>
> and only the one with the begin block seems to work for me, in both
> perl5.6.1 and perl5.8.0.
even with 5.005_03:
/tmp> perl-5.6.1 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; } die
"bar";'
foo
/tmp> perl-5.6.0 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; } die
"bar";'
foo
/tmp> perl-5.00503 -le 'BEGIN{ *CORE::GLOBAL::die = sub { print "foo" }; }
die "bar";'
foo
> Lincoln Stein wrote:
>
>> The fact is that this:
>>
>> *CORE::GLOBAL::die = \&mydie;
>>
>> Does not work with 5.6.0 or 5.6.1 and I am getting bug reports
>> regarding CGI::Carp. Here is a test script:
>>
>> #!/usr/bin/perl
>> use strict; *CORE::GLOBAL::die = \&mydie;
>> print STDERR "VERSION = $]\n"; print STDERR "line 1\n"; die "dieing
>> here\n"; print STDERR "line 2\n";
>> sub mydie { print STDERR "In die handler\n"; die $@; }
>> When I run it, I get:
>>
>> VERSION = 5.006 line 1 dieing here
>> Rather than the expected "In die handler" message.
>>
>> Please tell me what I am doing wrong.
>>
>> Lincoln
>>
>> On Monday 05 May 2003 04:44 pm, Jarkko Hietaniemi wrote:
>>
>>>> CGI::Carp is no longer working consistently for all combinations of
>>>> Perl and mod_perl versions. One way I have found to solve most of
>>>> the problems people are reporting is to backtrack and go back to
>>>> replacing the die handler this way:
>>>>
>>>> $SIG{__DIE__} = \&mydie;
>>>>
>>>> rather than
>>>>
>>>> *CORE::GLOBAL::die =&mydie;
>>>>
>>>> as is currently the case.
>>>>
>>>> The mailing lists are very confused (and confusing) on the issue of
>>>> the magic $SIG{__DIE__} data structure. Can you offer any advice?
>>>
>>>
>>> What seems to be the, umm, confusion? Reading perlfunc and perlvar
>>> on the subject I would say that $SIG{__DIE__} should *not* be used
>>> currently if one wants to write a 'handler' for die(). The problem
>>> is that the $SIG{__DIE__} is called also in evals.
>>
>>
>>
>
--
__________________________________________________________________
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
Re: CGI::Carp
Posted by Daisuke Maki <da...@wafu.ne.jp>.
It seems to me that CORE::GLOBAL::* can only be overridden at compile
time? I just did a quick test:
BEGIN{ *CORE::GLOBAL::die = sub { print "foo" } }
die "bar";
against
*CORE::GLOBAL::die = sub { print "foo" };
die "bar";
and only the one with the begin block seems to work for me, in both
perl5.6.1 and perl5.8.0.
--d
Lincoln Stein wrote:
> The fact is that this:
>
> *CORE::GLOBAL::die = \&mydie;
>
> Does not work with 5.6.0 or 5.6.1 and I am getting bug reports regarding
> CGI::Carp. Here is a test script:
>
> #!/usr/bin/perl
>
> use strict;
> *CORE::GLOBAL::die = \&mydie;
>
> print STDERR "VERSION = $]\n";
> print STDERR "line 1\n";
> die "dieing here\n";
> print STDERR "line 2\n";
>
> sub mydie {
> print STDERR "In die handler\n";
> die $@;
> }
>
> When I run it, I get:
>
> VERSION = 5.006
> line 1
> dieing here
>
> Rather than the expected "In die handler" message.
>
> Please tell me what I am doing wrong.
>
> Lincoln
>
> On Monday 05 May 2003 04:44 pm, Jarkko Hietaniemi wrote:
>
>>>CGI::Carp is no longer working consistently for all combinations of
>>>Perl and mod_perl versions. One way I have found to solve most of
>>>the problems people are reporting is to backtrack and go back to
>>>replacing the die handler this way:
>>>
>>> $SIG{__DIE__} = \&mydie;
>>>
>>>rather than
>>>
>>> *CORE::GLOBAL::die =&mydie;
>>>
>>>as is currently the case.
>>>
>>>The mailing lists are very confused (and confusing) on the issue of
>>>the magic $SIG{__DIE__} data structure. Can you offer any advice?
>>
>>What seems to be the, umm, confusion? Reading perlfunc and perlvar
>>on the subject I would say that $SIG{__DIE__} should *not* be used
>>currently if one wants to write a 'handler' for die(). The problem
>>is that the $SIG{__DIE__} is called also in evals.
>
>
Re: CGI::Carp
Posted by Lincoln Stein <ls...@cshl.org>.
The fact is that this:
*CORE::GLOBAL::die = \&mydie;
Does not work with 5.6.0 or 5.6.1 and I am getting bug reports regarding
CGI::Carp. Here is a test script:
#!/usr/bin/perl
use strict;
*CORE::GLOBAL::die = \&mydie;
print STDERR "VERSION = $]\n";
print STDERR "line 1\n";
die "dieing here\n";
print STDERR "line 2\n";
sub mydie {
print STDERR "In die handler\n";
die $@;
}
When I run it, I get:
VERSION = 5.006
line 1
dieing here
Rather than the expected "In die handler" message.
Please tell me what I am doing wrong.
Lincoln
On Monday 05 May 2003 04:44 pm, Jarkko Hietaniemi wrote:
> > CGI::Carp is no longer working consistently for all combinations of
> > Perl and mod_perl versions. One way I have found to solve most of
> > the problems people are reporting is to backtrack and go back to
> > replacing the die handler this way:
> >
> > $SIG{__DIE__} = \&mydie;
> >
> > rather than
> >
> > *CORE::GLOBAL::die =&mydie;
> >
> > as is currently the case.
> >
> > The mailing lists are very confused (and confusing) on the issue of
> > the magic $SIG{__DIE__} data structure. Can you offer any advice?
>
> What seems to be the, umm, confusion? Reading perlfunc and perlvar
> on the subject I would say that $SIG{__DIE__} should *not* be used
> currently if one wants to write a 'handler' for die(). The problem
> is that the $SIG{__DIE__} is called also in evals.
--
Lincoln Stein
lstein@cshl.org
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724
(516) 367-8380 (voice)
(516) 367-8389 (fax)
Re: CGI::Carp
Posted by Jarkko Hietaniemi <jh...@iki.fi>.
> CGI::Carp is no longer working consistently for all combinations of
> Perl and mod_perl versions. One way I have found to solve most of
> the problems people are reporting is to backtrack and go back to
> replacing the die handler this way:
>>
> $SIG{__DIE__} = \&mydie;
>
> rather than
>
> *CORE::GLOBAL::die =&mydie;
>
> as is currently the case.
>
> The mailing lists are very confused (and confusing) on the issue of
> the magic $SIG{__DIE__} data structure. Can you offer any advice?
What seems to be the, umm, confusion? Reading perlfunc and perlvar
on the subject I would say that $SIG{__DIE__} should *not* be used
currently if one wants to write a 'handler' for die(). The problem
is that the $SIG{__DIE__} is called also in evals.
--
Jarkko Hietaniemi <jh...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
CGI::Carp
Posted by Lincoln Stein <ls...@cshl.org>.
Hi Jarkko,
CGI::Carp is no longer working consistently for all combinations of Perl and
mod_perl versions. One way I have found to solve most of the problems people
are reporting is to backtrack and go back to replacing the die handler this
way:
$SIG{__DIE__} = \&mydie;
rather than
*CORE::GLOBAL::die =&mydie;
as is currently the case.
The mailing lists are very confused (and confusing) on the issue of the magic
$SIG{__DIE__} data structure. Can you offer any advice?
Lincoln
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Jarkko Hietaniemi <jh...@iki.fi>.
On Tue, Apr 15, 2003 at 06:55:18PM -0400, Lincoln Stein wrote:
> I've implemented the ability to pass $r to CGI and CGI::Cookie on
> initialization. This should make it easier to use CGI in earlier phases of
> the request cycle. It works for me, but please try it.
>
> Also fixed Jarkko's ticket 20710. It would be helpful if I were sent an
> e-mail message when problem tickets are posted. Jarkko, since i don't have
Unfortunately someone must notice that a bug report posted to the
generic Perl bug database is related to an external module, and then
manually forward the bug report to the author. Also unfortunately
there are quite a few bug reports coming in to this database, so
oftentimes the reports might fall through the cracks and not get
forwarded timely.
> an account on the bug tracking system, could you mark it as resolved?
Will do.
--
Jarkko Hietaniemi <jh...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Stas Bekman <st...@stason.org>.
Lincoln Stein wrote:
> Looks OK, but will need extensive testing. At one point I had a whole scheme
> worked out for loading different implementation modules as necessary: one for
> regular CGI, one for FastCGI, one for mod_perl and one for PerlEX. However,
> the risk of breaking compatibility with the thousands (hundreds of
> thousands?) of CGI.pm users has always dissuaded me from making dramatic
> architectural changes.
Well, the introduction of the new API, doesn't change any of the existing
features. CGI/CGI::Cookie use Apache->request for mod_perl, which could be
unavailable under mp2. So all we do is replacing Apache->request with call to
r() which uses $r if passed or calls the same old Apache->request. Obviously I
may be missing something, but I don't see any risks in introducing this change.
> On Thursday 10 April 2003 11:18 pm, Stas Bekman wrote:
>
>>Hi Lincoln,
>>
>>Nick Tonkin is working on the patch to make CGI::Cookie work properly under
>>modperl 2.0 in pre-response handlers, and the issue of providing the API
>>for passing $r to CGI.pm and CGI::Cookie has been raised again.
>>
>>I'm proposing the following API:
>>
>>- CGI.pm:
>>
>>CGI->r($r); # for non-OO API
>>
>>or
>>
>>my $q = CGI->new;
>>$q->r($r); # for OO API
>>
>>- CGI::Cookie
>>
>>CGI::Cookie::r($r);
>>
>>or something like that. Though we have to make into an account that CGI.pm
>>might be used in sub-requests, so we should probably make sure that we
>>aren't using the wrong global $r.
>>
>>and this is the implementation for CGI::Cookie (we need a similar one for
>>CGI.pm). I have also suggested to abstract all the mp functionality in a
>>separate module e.g., CGI/MP.pm, so we don't have to duplicate and maintain
>>several copies of the same code. Loading CGI.pm in CGI::Cookie sounds like
>>a bad idea if CGI is not already used elsewhere, because of the bloat.
>>
>>package CGI::Cookie;
>>..
>>use vars qw($gr); # global $r
>># get/set
>>sub r {
>> $gr = shift if @_;
>> return $gr || Apache->request;
>>}
>>sub new {
>> ...
>> if ($MOD_PERL) {
>> r()->pool->cleanup_register(\&CGI::Cookie::_reset_globals);
>> }
>>}
>>sub _reset_globals { initialize_globals(); }
>>sub initialize_globals {
>> $gr = undef;
>>}
>>
>>
>>
>>__________________________________________________________________
>>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
>
>
--
__________________________________________________________________
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
RE: Need help installing mod_perl
Posted by Tom Gazzini <to...@barzakh.co.uk>.
Thanks to all who offered helpful advice, it was much appreciated. I've
now got apache/mod_perl installed and running. Of course, Keep It Simple
was the answer.
The reason I ran into complications was that my web host pre-installed
my dedicated linux box with something called ensim. Now ensim is
web-based server administration tool, customized in this case for RH. It
gives you a nice graphic frontend (actually, not that nice) but messes
around a lot with the apache configuration and file layout.
In upgrading to Perl 5.8.0 and mod_perl 1.27, I was also trying to
preserve the ensim configuration, but that proved to be a nightmare.
I've now decided to ditch the graphical server admin tool, and opt
instead for a nice, simple standard apache setup and use of the SSH
command line. Life is better when it's simple.
Tom
Re: Need help installing mod_perl
Posted by Aaron Trevena <aa...@tuskerdirect.com>.
Tom Gazzini wrote
>Anyway, for sanity's sake (or what's left of it) I tried once again to
>type in the Makefile.PL args by hand exactly by the book (the Cookbook
>to be exact). So I typed the following:
>
>perl Makefile.PL \
>APACHE_SRC=../apache_1.3.27/src \
>APACHE_PREFIX=/usr/local/apache \
>EVERYTHING=1 \
>DO_HTTPD=1 \
>PORT=80 \
>USE_APACI=1 \
>APACI_ARGS='--enable-module=rewrite, \
> --enable-module=info, \
> --enable-module=expires, \
> --disable-module=userdir'
>
>"make && make test && make install" proceed without any problems.
>However, this doesn't use the file layout that I need (I'm using RH
>7.2). Also, I have to use PORT=80 because otherwise make test terminates
>with a "Cannot bind to port 8529, port already in use" error.
>
have you checked to see what is running on port 8529 ? do you have the
RH apache installation on it ?
>So I add '--with-layout=RedHat' to the APACI_ARGS above (and without
>changing anything else) and try again. This time "make && make test &&
>make install" work fine again. However, when I try and run httpd, I get
>the following error.
>
why use the redhat layout ? having your apache in one place instead of
scattered all over the shop is a good thing, you can then tar it up and
re-deploy effortlessly on a new machine (rty that with IIS)
>Syntax error on line 206 of /etc/httpd/conf/httpd.conf
>Invalid command 'LoadModule', perhaps mis-spelled or defined by a module
>not included in the server configuration.
>
hmm.. this may mean that Apache is using both the prefix and the layout
- like you told it - so just skip the redhat layout - then you can have
a working redhat apache to fall back to if your custom rolled apache
gets broken.
Also which versions of Apache and modperl is installed with redhat, and
which version of mod_perl are you building apache against ?
hope that helps,
A.
Re: Need help installing mod_perl
Posted by Stas Bekman <st...@stason.org>.
Others have already answered to most of your troubles, I'll add just one more bit:
>> Also, I have to use PORT=80 because otherwise make test terminates
>>with a "Cannot bind to port 8529, port already in use" error.
>
>
> Sounds like you could just use any other port that is unused, like 8530,
> 8531, etc.
When you get the "Cannot bind to port XXX, port already in use" error.
Use:
% ps auxc | grep httpd
to find all running httpd processes and
% ps auxc | grep httpd | perl -ane '`kill $F[1]`'
to kill them all.
of course if you haven't renamed the executable a simple:
% killall httpd
will do.
You could also kill httpds listening to a specific port, e.g. for 8529:
% netstat -pl |& grep 8529 | perl -ane '`kill @{[int $F[6]]}`'
of course this is adjusted for the output of netstat which may be different on
your platform (so do flags).
__________________________________________________________________
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
RE: Need help installing mod_perl
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2003-04-29 at 06:21, Tom Gazzini wrote:
> Anyway, for sanity's sake (or what's left of it) I tried once again to
> type in the Makefile.PL args by hand exactly by the book (the Cookbook
> to be exact). So I typed the following:
>
> perl Makefile.PL \
> APACHE_SRC=../apache_1.3.27/src \
> APACHE_PREFIX=/usr/local/apache \
> EVERYTHING=1 \
> DO_HTTPD=1 \
> PORT=80 \
> USE_APACI=1 \
> APACI_ARGS='--enable-module=rewrite, \
> --enable-module=info, \
> --enable-module=expires, \
> --disable-module=userdir'
Do you really require all of that extra configuration? Are you planning
to use mod_rewrite and mod_expires?
I typically use this one-liner:
perl Makefile.PL DO_HTTPD=1 USE_APACI=1 APACHE_PREFIX=/usr/local/apache
> "make && make test && make install" proceed without any problems.
> However, this doesn't use the file layout that I need (I'm using RH
> 7.2).
Is there any special reason you want to do it Red Hat's way? It's not
necessary, and their location is non-standard. Putting it in the
default /usr/local/apache/ is more typical and I've always run it that
way on Red Hat.
> Also, I have to use PORT=80 because otherwise make test terminates
> with a "Cannot bind to port 8529, port already in use" error.
Sounds like you could just use any other port that is unused, like 8530,
8531, etc.
> So I add '--with-layout=RedHat' to the APACI_ARGS above (and without
> changing anything else) and try again. This time "make && make test &&
> make install" work fine again. However, when I try and run httpd, I get
> the following error:
>
> Syntax error on line 206 of /etc/httpd/conf/httpd.conf
> Invalid command 'LoadModule', perhaps mis-spelled or defined by a module
> not included in the server configuration.
That's because you are running it with the httpd.conf file that Red Hat
made, even though you are now running a completely different server.
Theirs was compiled as a DSO, so it needed those directives. Your is
compiled statically, so it doesn't. You would be better off scrapping
their conf file and making your own, starting with the template that
comes with apache.
- Perrin
RE: Need help installing mod_perl
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi Tom,
On Tue, 29 Apr 2003, Tom Gazzini wrote:
> Secondly, I got tired of typing in the perl Makefile.PL .. with all the
> options time and time again, so I decided to use the
> makepl_args.mod_perl file
That's the way I always do it.
> However, this doesn't use the file layout that I need (I'm using RH7.2).
Get rid of the existing Apache and mod_perl installations, then use
whatever file layout you like.
> Also, I have to use PORT=80 because otherwise make test terminates
> with a "Cannot bind to port 8529, port already in use" error.
Hmmmm. Have you already got an Apache running from a previous build?
You shouldn't have two parent Apaches running at the same time until
you know how to handle that situation.
> The problematic line in httpd.conf is:
> LoadModule vhost_alias_module modules/mod_vhost_alias.so
>
> If I comment out that line I get the same error on the next LoadModule
> line, and it soon becomes apparent that pretty much all the LoadModule
> directives are failing.
Maybe you haven't compiled in mod_so? Never mind, in any case I'd
recommend a static build.
> So I start again
STOP! Take a deep breath. Clean up your directories, check what
processes you have running, kill any httpds that are there.
Then use the makepl_args.mod_perl method and everything will be fine
I'm sure.
> At this point I am at a complete loss as to what to do, so I spend a few
> hours repeating the same steps over and over and screaming silently.
You need to sit and study it a bit more. As you've found, repeating
the same failed steps over and over will get you nowhere.
73,
Ged.
RE: Need help installing mod_perl
Posted by Tom Gazzini <to...@barzakh.co.uk>.
> I can't understand what's the problem that you are having?
> You've supplied the
> error_log, which is cool, but not the output of 'make test'.
>
> Also don't you need to put quotes around APACI_ARGS args?
>
> APACI_ARGS='--enable-module=most, --enable-shared=max,
> --server-uid=apache,
> --server-gid=apache, --disable-shared=perl, --with-layout=RedHat'
>
> Finally, what's with --disable-shared=perl, have you read the
> installation
> instructions?
> http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_o
> of_a_Basic_mod_perl_Installation
> Are you trying to build DSO or static mod_perl?
Okay, allow me start again.
I'm trying to install mod_perl 1.27 on RH7.2. I've upgraded perl from
5.6.1 to 5.8.0
Firstly, yes I've read the installation instructions on the web, on the
INSTALL* files that come with the mod_perl source, AND in the chapter on
installing mod_perl in the Cookbook.
Secondly, I got tired of typing in the perl Makefile.PL .. with all the
options time and time again, so I decided to use the
makepl_args.mod_perl file ("Reusing Configuration Parameters" in the
documentation). Now, when you use this file I've found that it doesn't
seem to like you typing quotes around the APACI_ARGS args. It puts them
in itself (and if you type them in as well, it results in two pairs of
quotes and an error).
Anyway, for sanity's sake (or what's left of it) I tried once again to
type in the Makefile.PL args by hand exactly by the book (the Cookbook
to be exact). So I typed the following:
perl Makefile.PL \
APACHE_SRC=../apache_1.3.27/src \
APACHE_PREFIX=/usr/local/apache \
EVERYTHING=1 \
DO_HTTPD=1 \
PORT=80 \
USE_APACI=1 \
APACI_ARGS='--enable-module=rewrite, \
--enable-module=info, \
--enable-module=expires, \
--disable-module=userdir'
"make && make test && make install" proceed without any problems.
However, this doesn't use the file layout that I need (I'm using RH
7.2). Also, I have to use PORT=80 because otherwise make test terminates
with a "Cannot bind to port 8529, port already in use" error.
So I add '--with-layout=RedHat' to the APACI_ARGS above (and without
changing anything else) and try again. This time "make && make test &&
make install" work fine again. However, when I try and run httpd, I get
the following error:
Syntax error on line 206 of /etc/httpd/conf/httpd.conf
Invalid command 'LoadModule', perhaps mis-spelled or defined by a module
not included in the server configuration.
The problematic line in httpd.conf is:
LoadModule vhost_alias_module modules/mod_vhost_alias.so
If I comment out that line I get the same error on the next LoadModule
line, and it soon becomes apparent that pretty much all the LoadModule
directives are failing.
So I start again with the following:
perl Makefile.PL \
APACHE_SRC=../apache_1.3.27/src \
APACHE_PREFIX=/usr/local/apache \
EVERYTHING=1 \
DO_HTTPD=1 \
PORT=80 \
USE_APACI=1 \
APACI_ARGS='--enable-module=all, \
--enable-shared=max, \
--with-layout=RedHat'
This time make test terminates with the following error:
/usr/bin/perl t/TEST 0
not ok
Server failed to start! (please examine t/logs/error_log) at t/TEST line
95.
Make: *** [run_tests] Error 111
The file t/logs/error_log contains the following:
[notice] END block called for startup.pl
[notice] Destruction->DESTROY called for $global_object
[Tue Apr 29 03:10:59 2003] [warn] [notice] child_init for process 5480,
report any problems to [no address given]
At this point I am at a complete loss as to what to do, so I spend a few
hours repeating the same steps over and over and screaming silently. I
start taking longing looks at .NET websites, but guilt overcomes me and
I finally decide to come to this mailing list for help. HELP!
Tom
Re: Need help installing mod_perl
Posted by Stas Bekman <st...@stason.org>.
Tom Gazzini wrote:
> Hi all,
>
> I'm trying to build mod_perl 1.27 with apache 1.3.27 and perl 5.8.0. I
> am getting the following error_log after running make test:
>
> [Mon Apr 28 22:53:33 2003] [warn] pid file
> /home/nasser/src/mod_perl-1.27/t/logs/httpd.pid overwritten -- Unclean
> shutdown of previous Apache run?
> [notice] Destruction->DESTROY called for $global_object
> Subroutine fileparse_set_fstype redefined at
> /usr/lib/perl5/5.8.0/File/Basename.pm line 154.
> Subroutine fileparse redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
> line 168.
> Subroutine basename redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
> line 235.
> Subroutine dirname redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
> line 248.
> Constant subroutine CGI::XHTML_DTD redefined at
> /usr/lib/perl5/5.8.0/constant.pm line 108.
> [Mon Apr 28 22:53:34 2003] [warn] [notice] child_init for process 13238,
> report any problems to [no address given]
>
>
> This is the configuration I am using for perl Makefile.PL :
>
> APACHE_SRC=../apache_1.3.27/src
> APACHE_PREFIX=/usr
> EVERYTHING=1
> DO_HTTPD=1
> USE_APACI=1
> APACI_ARGS=--enable-module=most, --enable-shared=max,
> --server-uid=apache, --server-gid=apache, --disable-shared=perl,
> --with-layout=RedHat
>
> I can't see what I am doing wrong and have been tearing out what
> precious few hairs I have left all day. Can someone please help.
I can't understand what's the problem that you are having? You've supplied the
error_log, which is cool, but not the output of 'make test'.
Also don't you need to put quotes around APACI_ARGS args?
APACI_ARGS='--enable-module=most, --enable-shared=max, --server-uid=apache,
--server-gid=apache, --disable-shared=perl, --with-layout=RedHat'
Finally, what's with --disable-shared=perl, have you read the installation
instructions?
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation
Are you trying to build DSO or static mod_perl?
__________________________________________________________________
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
Need help installing mod_perl
Posted by Tom Gazzini <to...@barzakh.co.uk>.
Hi all,
I'm trying to build mod_perl 1.27 with apache 1.3.27 and perl 5.8.0. I
am getting the following error_log after running make test:
[Mon Apr 28 22:53:33 2003] [warn] pid file
/home/nasser/src/mod_perl-1.27/t/logs/httpd.pid overwritten -- Unclean
shutdown of previous Apache run?
[notice] Destruction->DESTROY called for $global_object
Subroutine fileparse_set_fstype redefined at
/usr/lib/perl5/5.8.0/File/Basename.pm line 154.
Subroutine fileparse redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
line 168.
Subroutine basename redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
line 235.
Subroutine dirname redefined at /usr/lib/perl5/5.8.0/File/Basename.pm
line 248.
Constant subroutine CGI::XHTML_DTD redefined at
/usr/lib/perl5/5.8.0/constant.pm line 108.
[Mon Apr 28 22:53:34 2003] [warn] [notice] child_init for process 13238,
report any problems to [no address given]
This is the configuration I am using for perl Makefile.PL :
APACHE_SRC=../apache_1.3.27/src
APACHE_PREFIX=/usr
EVERYTHING=1
DO_HTTPD=1
USE_APACI=1
APACI_ARGS=--enable-module=most, --enable-shared=max,
--server-uid=apache, --server-gid=apache, --disable-shared=perl,
--with-layout=RedHat
I can't see what I am doing wrong and have been tearing out what
precious few hairs I have left all day. Can someone please help.
Regards,
Tom
Re: CGI.pm 2.92 buglet
Posted by Lincoln Stein <ls...@cshl.org>.
Sorry about that. I applied a 3d party patch for an unrelated minor problem
and didn't pick up that it made the @ARGV change.
This is fixed in version 2.93.
Lincoln
On Monday 28 April 2003 12:53 pm, Perrin Harkins wrote:
> I ran into a bug this morning with CGI.pm 2.92. When using it with
> mod_perl 1.x, it does not pick up $r correctly because of a problem in
> the r() method. The attached patch fixes it.
>
> - Perrin
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================
Re: What's new with CGI.pm (was: RE: CGI.pm 2.92 buglet)
Posted by Stas Bekman <st...@stason.org>.
Frank Maas wrote:
>>AFAIK, nothing changes for mod_perl 1.0 users. So it's probably safe
>>to upgrade. However I suppose that you don't update your live service
>>with untested software, do you? So you should be all safe.
>
>
> Thanks Stas. I got curious because the bug Perrin found was while using
> it under MP1 (if I read his post correctly).
It was just a typo... you know one of those moments when a machine think it
knows better ;)
> As for updating... Once in
> a while I update my CPAN modules with the newest versions. And up until
> now (call me stupid) I have not found the way to downdate if there was a
> problem. But that's not mod_perl.
you mean s/downdate/downgrade/? I think you can find related discussions in
the archives. Or wait for our book to hit the bookstores somewhere next month.
http://www.oreilly.com/catalog/pmodperl/
A big part of Chapter 5 ("Web Server Control, Monitoring, Upgrade and
Maintenance") is talking about methodologies of doing upgrades and downgrades.
__________________________________________________________________
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
RE: What's new with CGI.pm (was: RE: CGI.pm 2.92 buglet)
Posted by Frank Maas <fr...@cheiron-it.nl>.
> AFAIK, nothing changes for mod_perl 1.0 users. So it's probably safe
> to upgrade. However I suppose that you don't update your live service
> with untested software, do you? So you should be all safe.
Thanks Stas. I got curious because the bug Perrin found was while using
it under MP1 (if I read his post correctly). As for updating... Once in
a while I update my CPAN modules with the newest versions. And up until
now (call me stupid) I have not found the way to downdate if there was a
problem. But that's not mod_perl.
--Frank
Re: What's new with CGI.pm (was: RE: CGI.pm 2.92 buglet)
Posted by Stas Bekman <st...@stason.org>.
Frank Maas wrote:
> Hi guys,
>
> I try to follow your ping-pong games about adding new things to CGI.pm.
> Since I use the module heavily under mod_perl 1.x, I was kind of startled
> by Perrin's mail, saying
>
>
>>>>I ran into a bug this morning with CGI.pm 2.92. When using it with
>>>>mod_perl 1.x, it does not pick up $r correctly because of a problem
>>>>in the r() method. The attached patch fixes it.
>>>
>
> I am currently using CGI.pm 2.91 and I am under the impression that
> changing into the now released 2.93 would change the world, but could
> also destroy that world. Can any of you (a) tell me what I can now
> do with 2.93 that I couldn't with 2.91 (something with $r perhaps) and
> (b) assure me that my apps won't bust if I do this update (you will
> not be brought to justice if you were wrong on this one ;-) ).
AFAIK, nothing changes for mod_perl 1.0 users. So it's probably safe to
upgrade. However I suppose that you don't update your live service with
untested software, do you? So you should be all safe.
The changes were done for mod_perl 2.0:
CGI.pm now allows to pass $r
my $q = CGI->new($r);
or
my $q = CGI->new();
$q->r($r);
CGI::Cookie now allows to pass $r:
CGI::Cookie::fetch($r);
Under mp2 when $r is passed explicitly the performance is better. You also may
need to do that if you use CGI.pm in pre-response handler phases.
Also there were several other changes unrelated to mod_perl, check the CGI.pm
changes list on its website.
__________________________________________________________________
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
What's new with CGI.pm (was: RE: CGI.pm 2.92 buglet)
Posted by Frank Maas <fr...@cheiron-it.nl>.
Hi guys,
I try to follow your ping-pong games about adding new things to CGI.pm.
Since I use the module heavily under mod_perl 1.x, I was kind of startled
by Perrin's mail, saying
>>> I ran into a bug this morning with CGI.pm 2.92. When using it with
>>> mod_perl 1.x, it does not pick up $r correctly because of a problem
>>> in the r() method. The attached patch fixes it.
I am currently using CGI.pm 2.91 and I am under the impression that
changing into the now released 2.93 would change the world, but could
also destroy that world. Can any of you (a) tell me what I can now
do with 2.93 that I couldn't with 2.91 (something with $r perhaps) and
(b) assure me that my apps won't bust if I do this update (you will
not be brought to justice if you were wrong on this one ;-) ).
Thanks all!
--Frank
Re: CGI.pm 2.92 buglet
Posted by Stas Bekman <st...@stason.org>.
Ged Haywood wrote:
> Hi Perrin,
>
> On 28 Apr 2003, Perrin Harkins wrote:
>
>
>>I ran into a bug this morning with CGI.pm 2.92. When using it with
>>mod_perl 1.x, it does not pick up $r correctly because of a problem in
>>the r() method. The attached patch fixes it.
>
>
> Good spot. Do you know how long the problem has been there?
For several hours. A new (fixed) CGI.pm 2.93 is available from CPAN.
__________________________________________________________________
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
Re: CGI.pm 2.92 buglet
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi Perrin,
On 28 Apr 2003, Perrin Harkins wrote:
> I ran into a bug this morning with CGI.pm 2.92. When using it with
> mod_perl 1.x, it does not pick up $r correctly because of a problem in
> the r() method. The attached patch fixes it.
Good spot. Do you know how long the problem has been there?
73,
Ged.
CGI.pm 2.92 buglet
Posted by Perrin Harkins <pe...@elem.com>.
I ran into a bug this morning with CGI.pm 2.92. When using it with
mod_perl 1.x, it does not pick up $r correctly because of a problem in
the r() method. The attached patch fixes it.
- Perrin
Re: a new API proposal for passing $r to CGI.pm/CGI::Cookie
Posted by Lincoln Stein <ls...@cshl.org>.
Looks OK, but will need extensive testing. At one point I had a whole scheme
worked out for loading different implementation modules as necessary: one for
regular CGI, one for FastCGI, one for mod_perl and one for PerlEX. However,
the risk of breaking compatibility with the thousands (hundreds of
thousands?) of CGI.pm users has always dissuaded me from making dramatic
architectural changes.
Lincoln
On Thursday 10 April 2003 11:18 pm, Stas Bekman wrote:
> Hi Lincoln,
>
> Nick Tonkin is working on the patch to make CGI::Cookie work properly under
> modperl 2.0 in pre-response handlers, and the issue of providing the API
> for passing $r to CGI.pm and CGI::Cookie has been raised again.
>
> I'm proposing the following API:
>
> - CGI.pm:
>
> CGI->r($r); # for non-OO API
>
> or
>
> my $q = CGI->new;
> $q->r($r); # for OO API
>
> - CGI::Cookie
>
> CGI::Cookie::r($r);
>
> or something like that. Though we have to make into an account that CGI.pm
> might be used in sub-requests, so we should probably make sure that we
> aren't using the wrong global $r.
>
> and this is the implementation for CGI::Cookie (we need a similar one for
> CGI.pm). I have also suggested to abstract all the mp functionality in a
> separate module e.g., CGI/MP.pm, so we don't have to duplicate and maintain
> several copies of the same code. Loading CGI.pm in CGI::Cookie sounds like
> a bad idea if CGI is not already used elsewhere, because of the bloat.
>
> package CGI::Cookie;
> ..
> use vars qw($gr); # global $r
> # get/set
> sub r {
> $gr = shift if @_;
> return $gr || Apache->request;
> }
> sub new {
> ...
> if ($MOD_PERL) {
> r()->pool->cleanup_register(\&CGI::Cookie::_reset_globals);
> }
> }
> sub _reset_globals { initialize_globals(); }
> sub initialize_globals {
> $gr = undef;
> }
>
>
>
> __________________________________________________________________
> 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
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
========================================================================