You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by stevan little <st...@iinteractive.com> on 2004/01/22 16:30:32 UTC
[Apache::Reload] possible patch/addition/feature (code included)
All,
(I sent this originally to Matt Sergeant, and he suggested i post it
here instead)
Apache::Reload a great module, there was however one thing that always
drove me crazy. When a module reload failed, I found myself alot of
times faced with the "Internal Server Error" page, and then i would
have to sludge through the error log.
My proposed patch/addition basically wraps the require code in an eval
block, and then if the require fails, it can catch the issue with $@.
It also then replaces the current mod_perl content handler with one
that will report the error to the browser. (It does this is a sorta
convoluted way by first pushing a PerlFixupHandler which then
re-assigns the PerlHandler. This is necessary because (for whatever
reason) changes to the PerlHandler done before the URI translation
phase will not stick.)
Its a pretty small addition. This is the new code in its entirety, it
basically falls in right where "require $module" would go:
##
------------------------------------------------------------------------
- ##
## Code to catch any module reload failures &
## force the error to display in the browser
##
------------------------------------------------------------------------
- ##
eval {
require $key;
warn("Apache::Reload: process $$ reloading $key\n")
if $DEBUG;
};
if ($@) {
my $e = $@;
$r->push_handlers("PerlFixupHandler" => sub {
my $r = shift;
$r->set_handlers("PerlHandler" => [ sub {
my $r = shift;
$r->send_http_header("text/html");
print "<H1>Module Error</H1><HR>" .
"$key failed to load<BR><PRE>$e</PRE>";
}
]);
}
);
warn("Apache::Reload: process $$ failed to reload $key\n") if
$DEBUG;
}
##
------------------------------------------------------------------------
- ##
The code is very mod_perl 1.0 specific, the way it does this is
probably not ok for mod_perl 2.0 (at least i think not, dont have a mp2
server handy to test it on).
I am not sure if you all think people would be interested in this
functionality. It takes a pretty radical approach to error handling by
subverting the normal apache content handler. It may not be for
everyone.
But you all are interested in it, I can certainly set up and mp2 server
(just give me an excuse :) and port this over.
Let me know what you think.
Thanks,
Stevan Little
stevan@iinteractive.com
p.s. - I apologize for not sending this in the form of a patch, but I
am new to the "contributing" end of open source software (after years
of "using"). I will get better, I promise.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Apache::Reload] possible patch/addition/feature (code included)
Posted by stevan little <st...@iinteractive.com>.
Stas,
Thanks for taking time out to answer my post.
On Jan 22, 2004, at 9:49 PM, Stas Bekman wrote:
> stevan little wrote:
>> All,
>> (I sent this originally to Matt Sergeant, and he suggested i post it
>> here instead)
>> Apache::Reload a great module, there was however one thing that
>> always drove me crazy. When a module reload failed, I found myself
>> alot of times faced with the "Internal Server Error" page, and then
>> i would have to sludge through the error log.
>> My proposed patch/addition basically wraps the require code in an
>> eval block, and then if the require fails, it can catch the issue
>> with $@. It also then replaces the current mod_perl content handler
>> with one that will report the error to the browser. (It does this is
>> a sorta convoluted way by first pushing a PerlFixupHandler which
>> then re-assigns the PerlHandler. This is necessary because (for
>> whatever reason) changes to the PerlHandler done before the URI
>> translation phase will not stick.)
>
> Thank you for the proposal, Stevan,
>
> Personally I don't think this is a desired behavior to be in the core.
> Others may think differently.
Sorry, I have not been tracking mp2 dev all that closely (signed up
today, and read some back messages about Apache::Reload this morning),
so I didnt realize how Apache::Reload was being thought of for mp2.
Given what you say about non-HTTP modules, my proposal doesn't make
much sense then :)
>
> Can't you just do:
>
> CGI::Carp qw(fatalsToBrowser);
I have never tried this, I will test it out.
>
>> p.s. - I apologize for not sending this in the form of a patch, but I
>> am new to the "contributing" end of open source software (after
>> years of "using"). I will get better, I promise.
>
> That would certainly be useful. Please read:
> http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
> and other docs under: http://perl.apache.org/contribute/
>
Thanks for the links, I am gonna review them right now.
- steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Apache::Reload] possible patch/addition/feature (code included)
Posted by Stas Bekman <st...@stason.org>.
stevan little wrote:
> All,
>
> (I sent this originally to Matt Sergeant, and he suggested i post it
> here instead)
>
> Apache::Reload a great module, there was however one thing that always
> drove me crazy. When a module reload failed, I found myself alot of
> times faced with the "Internal Server Error" page, and then i would
> have to sludge through the error log.
>
> My proposed patch/addition basically wraps the require code in an eval
> block, and then if the require fails, it can catch the issue with $@.
> It also then replaces the current mod_perl content handler with one
> that will report the error to the browser. (It does this is a sorta
> convoluted way by first pushing a PerlFixupHandler which then
> re-assigns the PerlHandler. This is necessary because (for whatever
> reason) changes to the PerlHandler done before the URI translation
> phase will not stick.)
Thank you for the proposal, Stevan,
Personally I don't think this is a desired behavior to be in the core. Others
may think differently.
Can't you just do:
CGI::Carp qw(fatalsToBrowser);
re: mp2
In mp2 Apache::Reload is also used to reload modules which has nothing to do
with HTTP. So it can be run as PerlPreConnection handler, when there is no
HTTP client to send the information to.
Also in mp2 you can't send any response (besides error codes) before the
PerlResponseHandler, so it just won't work.
> p.s. - I apologize for not sending this in the form of a patch, but I
> am new to the "contributing" end of open source software (after years
> of "using"). I will get better, I promise.
That would certainly be useful. Please read:
http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
and other docs under: http://perl.apache.org/contribute/
Looking forward for your other contributions.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org