CGI::Application & mod

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I've been exploring mod_perl lately. I like it but.... I'm getting what seems to me to be some odd behaviour, that I can't make sense of.

If I uncomment out the die marked with #NOTE1 (and restart the server) I get the standard 500 error not the die message I would expect ('UGGGGH!', this mesg. does show up in the logs however.)
If I re-comment the die, I get the 'huh' I expect (no need to restart the server).

I don't understand this behaviour.
Question 1 What do I have to do to get CGI::Carp (fatalsToBrowser) to work under mod_perl? This code works as I expect when not under mod_perl.
If I uncomment the error_mode liine I get what I expect in the browser ('Oops and $@'), but not the Carp msg.
Question 2 Why and when do I have to restart the server?
Apache/2.0.52 (Unix) mod_perl/1.999.21 Perl/v5.8.0

#! /usr/bin/perl -w
                                                                      
+          
package Comcoa;
use base 'CGI::Application';
use CGI::Carp qw(fatalsToBrowser);
use strict;
                                                                      
+          
sub setup {
    my $self = shift;
    $self->start_mode('start');
    #$self->error_mode('error');
    $self->run_modes(
        'start' => 'start',
        'test'  => 'test');
}
                                                                      
+          
sub test {
    die 'ARRRGH!';
}
                                                                      
+          
sub start {
    #die 'UGGGGH!'; #NOTE1
   'huh';
}
                                                                      
+          
sub error {
    "Oops we have an error?<p>$@";
}
                                                                      
+          
1;
[download]

Comment on CGI::Application & mod_perl Download Code

Replies are listed 'Best First'.
Re: CGI::Application & mod_perl by dragonchild (Archbishop) on Feb 01, 2005 at 01:33 UTC
Are you using mod_cgi or mod_registry? Or, is this an actual mod_perl handler? If you're using mod_cgi, you don't need to restart because mod_perl isn't actually doing anything. If you're using mod_registry (or whatever it's called), you have to restart the server every time you make a change (unless, of course, you're using some sort of reload-on-demand option). Additionally, I would do something like: `sub setup { my $self = shift; $self->start_mode('start'); $self->run_modes([qw( start test )]); }` [download] That's more CGIApp-ish. :-) Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply] [d/l]
Re: CGI::Application & mod_perl by perrin (Chancellor) on Feb 01, 2005 at 03:40 UTC
Does this work for you without mod_perl? I don't think CGI::Application plays well with fatalsToBrowser.	[reply]
Re^2: CGI::Application & mod_perl by hsinclai (Deacon) on Feb 01, 2005 at 16:22 UTC
I don't think CGI::Application plays well with fatalsToBrowser. I have to apologize, to CountZero too - I was totally wrong on this - fatalsToBrowser works fine - I've been having my mix of mod_perl and CGI configured wrong - as I discovered now after looking into this, but now fixed it. fatalsToBrowser works fine with mod_perl with nothing else required.. must be CGI::Application causing the problem in the OP's question. Downvote me severely.	[reply]
Re: CGI::Application & mod_perl by hsinclai (Deacon) on Feb 01, 2005 at 01:51 UTC
What do I have to do to get CGI::Carp (fatalsToBrowser) With mod_perl you have to write your own __DIE__ and __WARN__ signal handlers to get that to happen "If you want to redirect this information to the client instead of to error_log you have to take the responsibility yourself, by writing your own exception handler" is from this Bummer... Apparently the default behavior is to write to the errorlog for any exceptions raised.. so Carp kind of gets ignored.. Whether you're using `PerlModule Apache::PerlRun or PerlModule Apache::Registry` [download] changes your restart behavior.. PerlRun runs normal perl scripts without modification.. probably no restart required.. Registry runs mod_perl which wraps your script and can cause "function redefined" errors .. if plugging in an existing script..	[reply] [d/l]
Re^2: CGI::Application & mod_perl by perrin (Chancellor) on Feb 01, 2005 at 03:06 UTC
If you read a little farther down that page you'll see it says that CGI::Carp does this for you. It should work normally. There may be something about CGI::Application or this person's config that is breaking it.	[reply]
Re^3: CGI::Application & mod_perl by hsinclai (Deacon) on Feb 01, 2005 at 03:30 UTC
Well, exceptions send a 500 to the browser and get logged to the container's errorlog in my mod_perl setup running under either PerlRun or Registry, so without CGI::Application, it's not working for me either now or in the past.. fatalsToBrowser doesn't work out of the box. You still have to write something to handle exceptions and include a reference to it by altering %SIG.	[reply]
Re^2: CGI::Application & mod_perl by CountZero (Bishop) on Feb 01, 2005 at 06:53 UTC
I have CGI::Carp(fatalsToBrowser) in my (test) scripts and it works as expected in a mod_perl setup. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^3: CGI::Application & mod_perl by Anonymous Monk on Feb 01, 2005 at 17:49 UTC
Hmm... and I just convinced myself it couldn't be done. What could I be doing wrong? `#!/usr/bin/perl + package Apache::mod_test; use CGI::Carp qw(fatalsToBrowser); + sub handler { die 'oops'; } + 1;` [download] 500 error in browser. In the error logs I get: `[Tue Feb 01 09:36:20 2005] [error] [client 192.168.2.3] oops at /usr/l +ib/perl5/5.8.0/CGI/Carp.pm line 314.` [download]	[reply] [d/l] [select]
Re: CGI::Application & mod_perl by CountZero (Bishop) on Feb 01, 2005 at 07:09 UTC
There is probably something in CGI::Application that intercepts calls to `die` as there is a special method `error_mode()` that gets called in case one of your run-modes goes belly-up. CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply] [d/l] [select]