FAQ
Hi,

I'm trying to get different logging levels in the development and testing environments. It looks like it should be quite simple, but I think I've missed something somewhere.

The default configuration of the development server (script/app_server.pl) sends messages about the actions which have executed and all levels of log messages to the standard error. That's great.

When I deploy it to the test server (Zeus) under fastcgi (script/app_fastcgi.pl) it sends all this information to the Zeus logs. That's not so good, there's a lot of it.

The base module (lib/app.pm) contains "use Catalyst qw ~-Debug~". Get rid of the -Debug. Now it doesn't send the list of actions executed to the logs. Good. However it still logs all levels of messages.

Add __PACKAGE__->log( Catalyst::Log->new( 'warn', 'error' ) ); to app.pm. That sorts out the message levels. Good.

Unfortunately I haven't got enough information in the development environment any more.
From the documentation, I just need to set CATALYST_DEBUG=1 or APP_DEBUG=1 (and export them) and the output on the development environment should return to how it was at the beginning. Ie All levels of logging plus lots of extra stuff about actions executed.
Setting the environment variables doesn't work. I've missed something simple.

Any ideas?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20101022/eceddb5d/attachment.htm

Search Discussions

  • Eden Cardim at Oct 23, 2010 at 4:43 pm
    "Duncan" == Duncan Garland writes:
    Duncan> Hi, I?m trying to get different logging levels in the
    Duncan> development and testing environments. It looks like it
    Duncan> should be quite simple, but I think I?ve missed something
    Duncan> somewhere.

    Duncan> The default configuration of the development server
    Duncan> (script/app_server.pl) sends messages about the actions
    Duncan> which have executed and all levels of log messages to the
    Duncan> standard error. That?s great.

    Duncan> When I deploy it to the test server (Zeus) under fastcgi
    Duncan> (script/app_fastcgi.pl) it sends all this information to the
    Duncan> Zeus logs. That?s not so good, there?s a lot of it.

    Duncan> The base module (lib/app.pm) contains ?use Catalyst qw
    Duncan> ~-Debug~?. Get rid of the ?Debug. Now it doesn?t send the
    Duncan> list of actions executed to the logs. Good. However it still
    Duncan> logs all levels of messages.

    Duncan> Add __PACKAGE__->log( Catalyst::Log->new( 'warn', 'error' )
    Duncan> ); to app.pm. That sorts out the message levels. Good.

    Duncan> Unfortunately I haven?t got enough information in the
    Duncan> development environment any more.

    Duncan> From the documentation, I just need to set CATALYST_DEBUG=1
    Duncan> or APP_DEBUG=1 (and export them) and the output on the
    Duncan> development environment should return to how it was at the
    Duncan> beginning. Ie All levels of logging plus lots of extra stuff
    Duncan> about actions executed.

    The debug flag only enables the debug level and the per-request
    information. If you want per-environment settings, I'd recommend you
    break your configuration down into separate configuration files for each
    environment and use the configuration to set up the log flags.

    Something like (untested):

    MyApp.pm:

    my $env = $ENV{Catalyst::Util::class2env{__PACKAGE__}.'_ENV'} || 'dev';

    __PACKAGE__->config(
    'Plugin::ConfigLoader' => {
    file => __PACKAGE__->path_to('conf'),
    config_local_suffix => $env
    }
    );

    after setup_plugins => sub {
    my($class, $plugins) = @_;
    my $levels = $class->config->{Log}{level};
    $class->log->enable(@$levels);
    };

    conf/myapp_dev.conf:

    <Log>
    level warn
    level error
    </Log>

    Then run the app via MYAPP_ENV=test script/etc...

    This is going to use your regular myapp.conf file but override it with
    the environment-specific configuration which can be committed to your
    repository and version-controlled. Note that you can add as many
    environments as you wish, as long as you have an equivalent config file
    for it. You can also change the environment detection strategy in order
    to dodge having to declare the environment at all. I typically go with a
    combination of user/host names so that I get configuration files like:

    conf/myapp_edenc_home.conf
    conf/myapp_edenc_remoteserver1.conf
    conf/myapp_someotherdev_remoteserver1.conf
    conf/myapp_staging_remoteserver1.conf
    conf/myapp_production_remoteserver2.conf
    conf/myapp_production_remoteserver3.conf

    etc...

    This keeps things separate and avoids the typical mine/yours, dev/prod
    configuration hell. Of course, this assumes you're running
    production/staging apps under those usernames, YMMV.

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://blog.edencardim.com/ http://www.shadowcat.co.uk/servers/
  • Duncan Garland at Oct 26, 2010 at 8:24 am
    Thanks

    -----Original Message-----
    From: Eden Cardim
    Sent: 23 October 2010 17:43
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Debug Output
    "Duncan" == Duncan Garland <Duncan.Garland@motortrak.com> writes:
    Duncan> Hi, I?m trying to get different logging levels in the
    Duncan> development and testing environments. It looks like it
    Duncan> should be quite simple, but I think I?ve missed something
    Duncan> somewhere.

    Duncan> The default configuration of the development server
    Duncan> (script/app_server.pl) sends messages about the actions
    Duncan> which have executed and all levels of log messages to the
    Duncan> standard error. That?s great.

    Duncan> When I deploy it to the test server (Zeus) under fastcgi
    Duncan> (script/app_fastcgi.pl) it sends all this information to the
    Duncan> Zeus logs. That?s not so good, there?s a lot of it.

    Duncan> The base module (lib/app.pm) contains ?use Catalyst qw
    Duncan> ~-Debug~?. Get rid of the ?Debug. Now it doesn?t send the
    Duncan> list of actions executed to the logs. Good. However it still
    Duncan> logs all levels of messages.

    Duncan> Add __PACKAGE__->log( Catalyst::Log->new( 'warn', 'error' )
    Duncan> ); to app.pm. That sorts out the message levels. Good.

    Duncan> Unfortunately I haven?t got enough information in the
    Duncan> development environment any more.

    Duncan> From the documentation, I just need to set CATALYST_DEBUG=1
    Duncan> or APP_DEBUG=1 (and export them) and the output on the
    Duncan> development environment should return to how it was at the
    Duncan> beginning. Ie All levels of logging plus lots of extra stuff
    Duncan> about actions executed.

    The debug flag only enables the debug level and the per-request
    information. If you want per-environment settings, I'd recommend you
    break your configuration down into separate configuration files for each
    environment and use the configuration to set up the log flags.

    Something like (untested):

    MyApp.pm:

    my $env = $ENV{Catalyst::Util::class2env{__PACKAGE__}.'_ENV'} || 'dev';

    __PACKAGE__->config(
    'Plugin::ConfigLoader' => {
    file => __PACKAGE__->path_to('conf'),
    config_local_suffix => $env
    }
    );

    after setup_plugins => sub {
    my($class, $plugins) = @_;
    my $levels = $class->config->{Log}{level};
    $class->log->enable(@$levels);
    };

    conf/myapp_dev.conf:

    <Log>
    level warn
    level error
    </Log>

    Then run the app via MYAPP_ENV=test script/etc...

    This is going to use your regular myapp.conf file but override it with
    the environment-specific configuration which can be committed to your
    repository and version-controlled. Note that you can add as many
    environments as you wish, as long as you have an equivalent config file
    for it. You can also change the environment detection strategy in order
    to dodge having to declare the environment at all. I typically go with a
    combination of user/host names so that I get configuration files like:

    conf/myapp_edenc_home.conf
    conf/myapp_edenc_remoteserver1.conf
    conf/myapp_someotherdev_remoteserver1.conf
    conf/myapp_staging_remoteserver1.conf
    conf/myapp_production_remoteserver2.conf
    conf/myapp_production_remoteserver3.conf

    etc...

    This keeps things separate and avoids the typical mine/yours, dev/prod
    configuration hell. Of course, this assumes you're running
    production/staging apps under those usernames, YMMV.

    --
    Eden Cardim Need help with your Catalyst or DBIx::Class project?
    Code Monkey http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://blog.edencardim.com/ http://www.shadowcat.co.uk/servers/

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 22, '10 at 9:33a
activeOct 26, '10 at 8:24a
posts3
users2
websitecatalystframework.org
irc#catalyst

2 users in discussion

Duncan Garland: 2 posts Eden Cardim: 1 post

People

Translate

site design / logo © 2022 Grokbase