log¶

This method will return the current Log::Dispatch dispatcher object. The Log::Dispatch object is created on the first call to this method, and any subsequent calls will return the same object. This effectively creates a singleton log dispatcher for the duration of the request. If "log_config" has not been called before the first call to "log", then it will choose some sane defaults to create the dispatcher object (the exact default values are defined below).

  # retrieve the log object
  my $log = $self->log;
  $log->warning("something's not right!");
  $log->emergency("It's all gone pear shaped!");
 
  - or -
 
  # use the log object directly
  $self->log->debug(Data::Dumper::Dumper(\%hash));
  - or - 
  # if you configured it as a singleton
  My::App->log->debug('This works too');

log_config¶

This method can be used to customize the functionality of the CGI::Application::Plugin::LogDispatch module. Calling this method does not mean that a new Log::Dispatch object will be immediately created. The log object will not be created until the first call to $self->log.

The recommended place to call "log_config" is in the "cgiapp_init" stage of CGI::Application. If this method is called after the log object has already been accessed, then it will die with an error message.

If this method is not called at all then a reasonable set of defaults will be used (the exact default values are defined below).

The following parameters are accepted:

LOG_DISPATCH_OPTIONS

This allows you to customize how the Log::Dispatch object is created by providing a hash of options that will be passed to the Log::Dispatch constructor. Please see the documentation for Log::Dispatch for the exact syntax of the parameters. Surprisingly enough you will usually not need to use this option, instead look at the LOG_DISPATCH_MODULES option.

 LOG_DISPATCH_OPTIONS => {
      callbacks => sub { my %h = @_; return time().': '.$h{message}; },
 }
    

LOG_DISPATCH_MODULES

This option allows you to specify the Log::Dispatch::* modules that you wish to use to log messages. You can list multiple dispatch modules, each with their own set of options. Format the options in an array of hashes, where each hash contains the options for the Log::Dispatch:: module you are configuring and also include a 'module' parameter containing the name of the dispatch module. See below for an example. You can also add an 'append_newline' option to automatically append a newline to each log entry for this dispatch module (this option is not needed if you already specified the APPEND_NEWLINE option listed below which will add a newline for all dispatch modules).

 LOG_DISPATCH_MODULES => [ 
   {         module => 'Log::Dispatch::File',
               name => 'messages',
           filename => '/tmp/messages.log',
          min_level => 'info',
     append_newline => 1
   },
   {         module => 'Log::Dispatch::Email::MailSend',
               name => 'email',
                 to => [ qw(foo@bar.com bar@baz.org ) ],
             subject => 'Oh No!!!!!!!!!!',
          min_level => 'emerg'
   }
 ]
    

APPEND_NEWLINE

By default Log::Dispatch does not append a newline to the end of the log messages. By setting this option to a true value, a newline character will automatically be added to the end of the log message.

 APPEND_NEWLINE => 1
    

LOG_METHOD_EXECUTION (EXPERIMENTAL)

This option will allow you to log the execution path of your program. Set LOG_METHOD_EXECUTION to a list of all the modules you want to be logged. This will automatically send a debug message at the start and end of each method/function that is called in the modules you listed. The parameters passed, and the return value will also be logged. This can be useful by tracing the program flow in the logfile without having to resort to the debugger.

 LOG_METHOD_EXECUTION => [qw(__PACKAGE__ CGI::Application CGI)],
    

WARNING: This hasn't been heavily tested, although it seems to work fine for me. Also, a closure is created around the log object, so some care may need to be taken when using this in a persistent environment like mod_perl. This feature depends on the Sub::WrapPackages module.

DEFAULT OPTIONS¶

The following example shows what options are set by default (ie this is what you would get if you do not call log_config). A single Log::Dispatch::Screen module that writes error messages to STDERR with a minimum log level of debug.

 $self->log_config(
   LOG_DISPATCH_MODULES => [ 
     {        module => 'Log::Dispatch::Screen',
                name => 'screen',
              stderr => 1,
           min_level => 'debug',
      append_newline => 1
     }
   ],
 );

Here is a more customized example that uses two file appenders, and an email gateway. Here all debug messages are sent to /tmp/debug.log, and all messages above are sent to /tmp/messages.log. Also, any emergency messages are emailed to foo@bar.com and bar@baz.org.

 $self->log_config(
   LOG_DISPATCH_MODULES => [ 
     {    module => 'Log::Dispatch::File',
            name => 'debug',
        filename => '/tmp/debug.log',
       min_level => 'debug',
       max_level => 'debug'
     },
     {    module => 'Log::Dispatch::File',
            name => 'messages',
        filename => '/tmp/messages.log',
       min_level => 'info'
     },
     {    module => 'Log::Dispatch::Email::MailSend',
            name => 'email',
              to => [ qw(foo@bar.com bar@baz.org ) ],
          subject => 'Oh No!!!!!!!!!!',
       min_level => 'emerg'
     }
   ],
   APPEND_NEWLINE => 1,
 );