Re: [cgiapp] C::A, CAP::LogDispatch, error_mode(), and more!

[Cees Hek <suppressed>]

On Thu, 13 Jan 2005 13:03:10 -0600, Jason A. Crome <suppressed> wrote:
> Hello everyone,
> 
> I'm starting to add some logging functionality to my CGI::Application
> derived webapps, and after a lot of consideration, settled on using
> Log::Dispatch (by means of the plugin!  Thank you, Cees!) rather than
> rolling my own solution.  And so far, it's been great.

Glad to hear you find it useful.  I haven't heard much since I
released it, which is either a good thing 'cause it works wonderfully
well for everyone, or nobody is using it at all ;)

>  There's one
> thing I am trying to do, however, and I'm not sure that I can, or if I
> can, how to go about it ;)
> 
> For worst-case scenarios, I defined my own error runmode so that I can
> give the user a friendly error page rather than the dreaded "Internal
> Server Error" page Apache would normally serve up.  At some point before
> or after this, however, I'd like to catch whatever die() messages are
> being thrown and also log those using Log::Dispatch.

Can error_mode not handle this?  I can see the difficulty in using a
SIG handler for this, since you won't have access to the $self object,
but in an error_mode runmode you should have access to $self and hence
$self->log

sub setup {
  my $self = shift;

  $self->error_mode('my_error_rm');
}

sub my_error_rm {
  my $self = shift;
  $self->log->emerg($@); # I think $@ should still contain the last eval error
  return 'some html';
}

> In fact, I wouldn't mind catching any warnings either.

in development you could set perl to die on all warnings and capture
them that way.

use warnings FATAL => 'all';

But I wouldn't run that in production...

The other option would be for me to update the CAP::LogDispatch plugin
to work as a Singleton by saving the object in a class variable
instead of an object variable.   This means I could make the log
method also work as a class method.

So you could call

$self->log;

- or -

MyApp->log;

With that you could easily write a signal handler.

$SIG{WARN} = sub { MyApp->log->warn(shift) };

This would mean that once you create the log object, it would never go
out of scope, and on subsequent requests you would get the same object
(in a persistent environment).   Also, you would still have to wait
until the log object is configured before you can access it, but I
guess log_config could work as a class method as well, so you could
configure the object like this:

package MyCGI::App;

use CGI::Application::Plugin::LogDispatch;

MyCGI::App->log_config(
  LOG_DISPATCH_MODULES => [
            { module => 'Log::Dispatch::Screen',
               name => 'screen',}
  ]
);

Or maybe even simpler:

use CGI::Application::Plugin::LogDispatch (
  LOG_DISPATCH_MODULES => [
            { module => 'Log::Dispatch::Screen',
               name => 'screen',}
  ]
);


I am planning to do something similar with the Template Toolkit plugin
as well, so that the templates don't have to be recompiled on each
request (for those using persistent environments that will provide a
real boost).

Let me know if you think that would solve your problems and I'll see
how easy it is to implement...

Cheers,

-- 
Cees Hek

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed