log4perl-devel — Ongoing log4perl development

[log4perl-devel] Log::Log4perl 1.30

[Mike S. <m...@pe...>]

Log4perl enthusiasts,

Log::Log4perl 1.30 just made it to CPAN. This maintenance release
contains the following fixes:

1.30 (2010/08/30)

    *    (ms) [RT 60665] HUP handlers are stacked on top of each other
         now, to make sure that multiple file appenders recreate
         multiple files and not just one (patch provided by Karen
         Etheridge).

    *    (ms) [RT 60197] Fixed uninitialized value warnings with the
         multiline appender and provided a test case (patch provided by
         Karen Etheridge)

    *    (ms) [rt.cpan.org #59617] Fixed system-wide threshold without
         appender thresholds. Bug reported by Dmitry Bigunyak.

    *    (ms) [rt.cpan.org #24884] Using require() instead of
         incomplete logic in L4p::Util::module_available(). local
         __DIE__ handler takes care of user-defined __DIE__ handlers
         ignoring $^S (suggested by Eric Wilhelm and others).

    *    (ms) [rt.cpan.org #60386] Fixed init_and_watch() which double-
         bumped the caller_level and led to uninitialized values in the
         pattern layout. Thanks to Mitja Bartsch for the report.

    *    (ms) Applied patch by Karsten Silkenbäumer to add an optional
         $log_dispatch_level to create_custom_level(). Updated
         documentation.

Thanks to all contributors!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] eradicate / NFS

[Mike S. <m...@pe...>]

On Mon, 16 Aug 2010, fou...@bi... wrote:

> we start logging prior to the temporary appender creation. So if we
> set create_at_logtime and put all the temp app config in the main log
> config, l4p tries to create the temp logfile before the creation of
> the temp dir meant to contain the temp logfile...

Somehow the use of a configuration file seems to defy the purpose of
this particular use case. The configuration is usually read at start-up
and determines the program's logging behavior.

What you could do to point Log4perl at a tempfile created sometime at
runtime, is obtain a reference to the file appender the configuration
uses (or add another file appender via perl code) and use the file
appender's file_switch( $newfile ) mode to point it to a newly created
file.

This might surprise your users, though, so be warned.

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] unable to install Log::Log4perl on Fedora 8 for Amazon::S3 use

[Mike S. <m...@pe...>]

On Tue, 17 Aug 2010, Mahesh Shinde wrote:

> Thanks and Regards, Mahesh Shinde

It would help us diagnose the problem if you send the commands you used
to install Log::Log4perl and the error message(s) you received.

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] unable to install Log::Log4perl on Fedora 8 for Amazon::S3 use

[Mahesh S. <Mah...@pe...>]

Thanks and Regards,
Mahesh Shinde |Software Engineer|Persistent Systems limited
mah...@pe...<mailto:mah...@pe...>  (+91-40-308) 74200  cel: 09542371575
Innovation in software product design, development and delivery- www.persistentsys.com<https://puneexchange.persistent.co.in/owa/UrlBlockedError.aspx>


DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

Re: [log4perl-devel] eradicate / NFS

[<fou...@bi...>]

Le 31/07/2010 02:25, Mike Schilli a écrit :
> On Wed, 28 Jul 2010, fou...@bi... wrote:
> 
>> then the temporary log file seems to get
>> created in the beginning... leading to an error because of the missing
>> temporary directory...
> 
> The file appender lets you delay creation of the file until you write to
> it, check the create_at_logtime option in
> 
>      http://search.cpan.org/~mschilli/Log-Log4perl-1.29/lib/Log/Log4perl/Appender/File.pm

Hi Mike,
I was aware of that option, and I thought it was inappropriate in our context.
Now I have tested it and I can tell it's inappropriate:
we start logging prior to the temporary appender creation. So if we set create_at_logtime and put all the temp app config in the main log config, l4p tries to create the temp logfile before the creation of the temp dir meant to contain the temp logfile...

>> That's the expected behaviour, but the code snippets comes from a single script, so there should not be any other reference to the temporary appender.
> 
> Can you post a standalone script that reproduces the error?

It took some time, but here it is (attachment).

Re: [log4perl-devel] eradicate / NFS

[Mike S. <m...@pe...>]

On Wed, 28 Jul 2010, fou...@bi... wrote:

> then the temporary log file seems to get
> created in the beginning... leading to an error because of the missing
> temporary directory...

The file appender lets you delay creation of the file until you write to
it, check the create_at_logtime option in

     http://search.cpan.org/~mschilli/Log-Log4perl-1.29/lib/Log/Log4perl/Appender/File.pm

> That's the expected behaviour, but the code snippets comes from a single script, so there should not be any other reference to the temporary appender.

Can you post a standalone script that reproduces the error?

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] eradicate / NFS

[<fou...@bi...>]

Le 10/07/2010 08:02, Mike Schilli a écrit :
> On Tue, 6 Jul 2010, Foudil wrote:
> 
>> In order to log to a tmp directory (that we want to remove later), we
>> create an appender in a script that we add to our project's loggers:
>> Log::Log4perl->init_and_watch($path_conf."/log.conf", 'HUP');
> 
> Hi Foudil,
> 
> sorry for the long wait. I've noticed that you're using init_and_watch()
> along with user-defined appenders. Just a heads-up that this can lead to
> unpredictable situations: Whenever Log4perl/init_and_watch() notices
> that it needs to reload the configuration file (because it has changed),
> you'll lose the temporary appender, because the Log4perl configuration
> will be overwritten.
> 
> Even if you don't need the appender permanently, it makes sense to have
> it in the configuration, if only for reasons of clarity.

Hi Mike,

[also sorry for the delay]

Thank you for the hint. I'm not sure how to put the configuration for the temporary appender in the general configuration file: because the temporary file appender needs to get created during the execution in a temporary directory (that gets created itself during execution). Whereas if the configuration for the temporary file appender is in the general configuration file, then the temporary log file seems to get created in the beginning... leading to an error because of the missing temporary directory...

>>    Log::Log4perl->eradicate_appender($local_appender_name);
>>    # ...but the appender is still alive and keeps filehandles open. So we need
>>    #  to close them explicitly.
> 
> The eradicate_appender() method should take are of the issue in this
> situation. Only exception: if still have references to the appender 
> anywhere in your application code, the appender destructor won't run and
> you need to run file_close() manually.

That's the expected behaviour, but the code snippets comes from a single script, so there should not be any other reference to the temporary appender. And what I could observe under NFS is that the appender *somehow* keeps the filehandle open. I just wanted to warn about this "somehow" (probably related to "NFS silly renames" ?), and maybe learn how to deal with it.

Best,
Foudil

Re: [log4perl-devel] Feature request - complaint

[Mike S. <m...@pe...>]

On Mon, 19 Jul 2010, Tomáš Nechutný wrote:

> This module is a copy of this C code (a bit generalized). Altough it's
> really simple piece of code, I thought it could be useful for other
> peoples and I don't know any other use cases than logging so I'm
> posting it here (patch attached). I'll make better docs ASAP.

Hi Tomá,

interesting idea, but I think this module could stand on its own and 
isn't necessarily related to Log4perl. How about you add documentation 
and push it to CPAN under, say, Collectd::Complaint ?

-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] Feature request - complaint

[Tomáš N. <ne...@gm...>]

Hello,

I work on a project consiting of daemon which runs periodically (10 - 300 
seconds) some bits of code (check nginx status, check presence of some 
processes, ...). This daemon runs on our servers. I use log4perl everywhere. 

However sometimes an admin shuts down nginx for a while (0 - few hours) and do 
some maintainance. Nginx code logs errors when HTTP requests fails. Log file 
is then filled with same repeated message(s).

When I browsed through collectd (monitoring of everything) I found 
utils_complain.[ch] which address this problem. It consists of structure which 
is associated with one error message and functions for logging (complaining, 
integrated into its logging system). It looks like this:

// inside collectd plugin, code executed periodically
c_complain(c, ERROR, "connecting failed");

The above logs only if (c->last + c->interval) is less or equal time(). c-
>interval is doubled on every call. c->last is last time of logging.

After success c->interval is set to 0 with:

c_release(c);

This module is a copy of this C code (a bit generalized). Altough it's really 
simple piece of code, I thought it could be useful for other peoples and I 
don't know any other use cases than logging so I'm posting it here (patch 
attached). I'll make better docs ASAP.

Regards,
Thomas.

Re: [log4perl-devel] printf-like messages

[Mike S. <m...@pe...>]

On Thu, 8 Jul 2010, Tomáš Nechutný wrote:

> I can live without it (and use sprintf() return value as a parameter
> to log methods), but it would be nice.

Yeah, sprintf() should take care of all your formatting needs. I've
found that I use printf() very rarely in Perl, because you can
interpolate variables so elegantly in strings. Also, there's a lot of
hidden functionality in the loggers as is (think about loggers that take
fixed arguments like database loggers, or that you can pass a subroutine
to any logger which it will then evaluate), so having printf-like
functions would considerably complicate things. But thanks for the
suggestion!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] eradicate / NFS

[Mike S. <m...@pe...>]

On Tue, 6 Jul 2010, Foudil wrote:

> In order to log to a tmp directory (that we want to remove later), we
> create an appender in a script that we add to our project's loggers:
> Log::Log4perl->init_and_watch($path_conf."/log.conf", 'HUP');

Hi Foudil,

sorry for the long wait. I've noticed that you're using init_and_watch()
along with user-defined appenders. Just a heads-up that this can lead to
unpredictable situations: Whenever Log4perl/init_and_watch() notices
that it needs to reload the configuration file (because it has changed),
you'll lose the temporary appender, because the Log4perl configuration
will be overwritten.

Even if you don't need the appender permanently, it makes sense to have
it in the configuration, if only for reasons of clarity.

>    Log::Log4perl->eradicate_appender($local_appender_name);
>    # ...but the appender is still alive and keeps filehandles open. So we need
>    #  to close them explicitly.

The eradicate_appender() method should take are of the issue in this
situation. Only exception: if still have references to the appender 
anywhere in your application code, the appender destructor won't run and
you need to run file_close() manually.

Hope that helps!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] Why is Log::Log4perl opening unreferenced log files and can I stop it

[Martin J. E. <mar...@ea...>]

Kevin Goess wrote:
> Martin, see 'perldoc Log4perl::Appender::File
> 
> create_at_logtime
> The file appender typically creates its logfile in its constructor, i.e.
> at Log4perl "init()" time. This
> is desirable for most use cases, because it makes sure that file
> permission problems get detected right
> away, and not after days/weeks/months of operation when the appender
> suddenly needs to log something and
> fails because of a problem that was obvious at startup.
> 
> However, there are rare use cases where the file shouldn’t be created at
> Log4perl "init()" time, e.g. if
> the appender can’t be used by the current user although it is defined in
> the configuration file. If you
> set "create_at_logtime" to a true value, the file appender will try to
> create the file at log time. Note
> that this setting lets permission problems sit undetected until log
> time, which might be undesirable.

Kevin,

Thanks for pointing that out although I guess I missed this because I
was using Log::Dispatch::File (which does not have create_at_log) and
not Log::Log4perl::Appender::File. When I change to
Log::Log4perl::Appender::File and set the create_at_log it works fine.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com


> 
> 
> Martin J. Evans wrote:
>> Hi,
>>
>> I have a number of daemon processes using Log::Log4perl and tens of
>> modules shared between them also using Log::Log4perl. All the log4perl
>> configuration is in a single file for convenience (as most modules in it
>> are common). Each perl module has its own log entry and logs to a
>> different file. The problem is there are ALOT of different log files
>> defined and Log4perl seems to open every file mentioned in the config
>> file even though only a handful might be used. e.g.,
>>
>> config:
>> log4perl.logger.XXX.module1 = INFO, MONE
>> log4perl.appender.MONE=Log::Dispatch::File
>> log4perl.appender.MONE.filename=/tmp/file1.log
>>
>> log4perl.logger.XXX.module2 = INFO, MTWO
>> log4perl.appender.MTWO=Log::Dispatch::File
>> log4perl.appender.MTWO.filename=/tmp/file2.log
>> .
>> .
>> .
>> etc
>>
>> and daemon1 uses module XXX::module1 but not XXX.module2, the
>> /tmp/file2.log is opened in daemon1 even though it is never going to be
>> logged to. This is rather annoying since it is using up my open file
>> descriptors etc.
>>
>> Using lsof on a single daemon shows dozens of log files open even though
>> there is NO chance it will log anything to them.
>>
>> Is there any way to stop this?
>>
>> Thanks.
>>
>> Martin
>>   
> 

[log4perl-devel] printf-like messages

[Tomáš N. <ne...@gm...>]

Hello,

I would like to request a feauture for printf-like logging via ->log(), -
>debug(), 

I tried to implement it by myself by subclassing Log::Log4perl (override 
get_logger() to delegage get_logger to my Logger class) and 
Log::Log4perl::Logger (override ->generate_coderef() to do sprintf() before 
passing parameters to the original coderef). However I don't like the way I 
had to override get_logger(), so I decided I rather request it as a feature 
here.

Is it interesting? I can live without it (and use sprintf() return value as a 
parameter to log methods), but it would be nice.

Thank for response.
Thomas.

Re: [log4perl-devel] Why is Log::Log4perl opening unreferenced log files and can I stop it

[Kevin G. <cp...@go...>]

Martin, see 'perldoc Log4perl::Appender::File

create_at_logtime
The file appender typically creates its logfile in its constructor, i.e. 
at Log4perl "init()" time. This
is desirable for most use cases, because it makes sure that file 
permission problems get detected right
away, and not after days/weeks/months of operation when the appender 
suddenly needs to log something and
fails because of a problem that was obvious at startup.

However, there are rare use cases where the file shouldn’t be created at 
Log4perl "init()" time, e.g. if
the appender can’t be used by the current user although it is defined in 
the configuration file. If you
set "create_at_logtime" to a true value, the file appender will try to 
create the file at log time. Note
that this setting lets permission problems sit undetected until log 
time, which might be undesirable.



Martin J. Evans wrote:
> Hi,
>
> I have a number of daemon processes using Log::Log4perl and tens of
> modules shared between them also using Log::Log4perl. All the log4perl
> configuration is in a single file for convenience (as most modules in it
> are common). Each perl module has its own log entry and logs to a
> different file. The problem is there are ALOT of different log files
> defined and Log4perl seems to open every file mentioned in the config
> file even though only a handful might be used. e.g.,
>
> config:
> log4perl.logger.XXX.module1 = INFO, MONE
> log4perl.appender.MONE=Log::Dispatch::File
> log4perl.appender.MONE.filename=/tmp/file1.log
>
> log4perl.logger.XXX.module2 = INFO, MTWO
> log4perl.appender.MTWO=Log::Dispatch::File
> log4perl.appender.MTWO.filename=/tmp/file2.log
> .
> .
> .
> etc
>
> and daemon1 uses module XXX::module1 but not XXX.module2, the
> /tmp/file2.log is opened in daemon1 even though it is never going to be
> logged to. This is rather annoying since it is using up my open file
> descriptors etc.
>
> Using lsof on a single daemon shows dozens of log files open even though
> there is NO chance it will log anything to them.
>
> Is there any way to stop this?
>
> Thanks.
>
> Martin
>   

[log4perl-devel] Why is Log::Log4perl opening unreferenced log files and can I stop it

[Martin J. E. <mar...@ea...>]

Hi,

I have a number of daemon processes using Log::Log4perl and tens of
modules shared between them also using Log::Log4perl. All the log4perl
configuration is in a single file for convenience (as most modules in it
are common). Each perl module has its own log entry and logs to a
different file. The problem is there are ALOT of different log files
defined and Log4perl seems to open every file mentioned in the config
file even though only a handful might be used. e.g.,

config:
log4perl.logger.XXX.module1 = INFO, MONE
log4perl.appender.MONE=Log::Dispatch::File
log4perl.appender.MONE.filename=/tmp/file1.log

log4perl.logger.XXX.module2 = INFO, MTWO
log4perl.appender.MTWO=Log::Dispatch::File
log4perl.appender.MTWO.filename=/tmp/file2.log
.
.
.
etc

and daemon1 uses module XXX::module1 but not XXX.module2, the
/tmp/file2.log is opened in daemon1 even though it is never going to be
logged to. This is rather annoying since it is using up my open file
descriptors etc.

Using lsof on a single daemon shows dozens of log files open even though
there is NO chance it will log anything to them.

Is there any way to stop this?

Thanks.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

[log4perl-devel] eradicate / NFS

[Foudil <fou...@fr...>]

Hi all,

In order to log to a tmp directory (that we want to remove later), we create an appender in a script that we add to our project's loggers:

Log::Log4perl->init_and_watch($path_conf."/log.conf", 'HUP'); # HUP needed for logrotate
my $logger = get_logger($FindBin::Script);
my $logger_all = Log::Log4perl->get_logger("OurProject");
# Local appender to log in tmp directory.
my $local_appender;
my $local_appender_name = 'LogTmp';

...

    # Create appender to log error in tmp directory.
    $local_appender = Log::Log4perl::Appender->new(
        "Log::Log4perl::Appender::File",
        name      => $local_appender_name,
        filename  => "$spool_tmp/error.log",
        mode      => 'write',
        syswrite  => 1,
        utf8      => 1,
       );
    my $layout = Log::Log4perl::Layout::PatternLayout->new("%d %P %p> %F{1}:%L %M - %m%n");
    $local_appender->layout($layout);
    $local_appender->threshold($CFG{'l4p_appender_logtmp_threshold'});
    $logger->add_appender($local_appender);
    $logger_all->add_appender($local_appender); # add appender to project modules' logger

...

    $logger->remove_appender($local_appender_name);
    $logger_all->remove_appender($local_appender_name);
    rmtree($spool_tmp, {error => \my $err});
    if (@$err) {
        file_path_error($err);
        exit;
    }
    $logger->info("removed $spool_tmp");

But rmtree() (File::Path) is complaining that $spool_tmp is not empty. $spool_tmp is on an NFS mount.

So we solved the pb with:

    #$logger->remove_appender($local_appender_name);
    #$logger_all->remove_appender($local_appender_name);
    # "will first remove the appender from every logger in the system and then
    # will delete all references Log4perl holds to it." (Log::Log4perl)
    Log::Log4perl->eradicate_appender($local_appender_name);
    # ...but the appender is still alive and keeps filehandles open. So we need
    #  to close them explicitly. Especially under NFS, where deleted but still
    #  opened files are kept by the kernel as '.nfsxxx' (see "NFS silly
    #  rename")
    $local_appender->file_close(); # (undocumented, look into the code)
    rmtree($spool_tmp, {error => \my $err});
    if (@$err) {
        file_path_error($err);
        exit;
    }
    $logger->info("removed $spool_tmp");

My guess may be wrong, and I'd be interested to know if there is a better solution.

Best
Foudil

[log4perl-devel] Log::Log4perl 1.29 Released

[Mike S. <m...@pe...>]

Hi Log4perl enthusiasts,

Log::Log4perl 1.29 has just been released to CPAN. New in this
release:

1.29 (2010/06/16)
    *    (ms) Added documentation on how to use Log4perl's :easy macros
              with Catalyst in Log::Log4perl::Catalyst.
    *    (ms) wrapper_register() now deals with caller_depth automatically.
              Backwards compatibility with old wrapper classes using
              caller_depth directly is provided. Documentation has been
              updated.
    *    (ms) Felix Antonius Wilhelm Ostmann reported Resurrector.pm
              crashes, fixed as suggested by setting the %INC value to
              the module path.
    *    (ms) Another caller_depth fix in Log::Log4perl::Catalyst.
    *    (ms) Fixed logdie() caller_depth bug reported by Rob Retter.
    *    (ms) [RT 56145] Saving errstr in DBI appender to survive ping()
    *    (ms) Added INTERNAL_DEBUG env variable to test suite triggering
              all _INTERNAL_DEBUG statements to be printed for better
              error diagnosis on misbehaving systems.

Enjoy!

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] DBIC Object not interpreted (fwd)

[Mike S. <m...@pe...>]

Forwarding Steve's answer to the list ...

-- Mike

Mike Schilli
m...@pe...

---------- Forwarded message ----------
From: Steve <st...@ma...>
To: Mike Schilli <m...@pe...>
Subject: Re: [log4perl-devel] DBIC Object not interpreted
Date: Tue, 11 May 2010 08:15:17 -0400


On 5/11/2010 1:25 AM, Mike Schilli wrote:
       On Mon, 10 May 2010, Steve wrote:

             Where $newsub is an object, the following fails
             to work as I expected it to:
             $logger->info("Created sub->", $newsub->ptn);
             Since my log is a text file, this yields the
             following line in the file:
             2010/05/10 16:38:59 INFO> cmsIMsubs-S.pl:176
             main::getSubs - Created
             sub->CMS::Schema::Result::Subscription=HASH(0x96b9164)->ptn
             In case it's not obvious, I'd like to log the
             phone number, not what type of object I'm looking
             at.


       I doubt this is related to Log4perl, I bet you'll get the
       same result
       with print(). Make sure that your ptn() method does the right
       thing when
       called in list (!) context.

I'm not quite sure why, but changing the double quotes around the
"Created sub->" to single quotes had the desired
effect?  Also, $newsub->ptn is an accessor method for DBIx::Class::Row
that should return the value of that particular
column, as it now does.

Thanks for the response!

       Here's some code to show that it works as expected:

           use strict;

           package Wobble;
           sub new { bless {}, shift; }
           sub ptn { return "wobble!" }

           package main;
           use Log::Log4perl qw(:levels get_logger);
           Log::Log4perl->easy_init($DEBUG);

           my $logger = get_logger();

           my $wobble = Wobble->new();
           $logger->info("return of ptn: ", $wobble->ptn());


       -- Mike

       Mike Schilli
       m...@pe...

  No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.819 / Virus Database: 271.1.1/2866 - Release Date: 05/10/10 14:26:00

Re: [log4perl-devel] DBIC Object not interpreted

[Tim B. <Tim...@po...>]

On Mon, May 10, 2010 at 04:42:37PM -0400, Steve wrote:
> Where $newsub is an object, the following fails to work as I expected it to:
> 
> $logger->info("Created sub->", $newsub->ptn);
>
> Since my log is a text file, this yields the following line in the file:
> 2010/05/10 16:38:59 INFO> cmsIMsubs-S.pl:176 main::getSubs - Created
> sub->CMS::Schema::Result::Subscription=HASH(0x96b9164)->ptn

Where does that "->ptn" in the message text come from?

If that is the actual line of code that's being executed then it seems
that the ptn() method is returning that string with the "->ptn" text.

Tim.

Re: [log4perl-devel] DBIC Object not interpreted

[Mike S. <m...@pe...>]

On Mon, 10 May 2010, Steve wrote:

> Where $newsub is an object, the following fails to work as I expected it to:
> $logger->info("Created sub->", $newsub->ptn);
> Since my log is a text file, this yields the following line in the file:
> 2010/05/10 16:38:59 INFO> cmsIMsubs-S.pl:176 main::getSubs - Created 
> sub->CMS::Schema::Result::Subscription=HASH(0x96b9164)->ptn
> In case it's not obvious, I'd like to log the phone number, not what type of 
> object I'm looking at.

I doubt this is related to Log4perl, I bet you'll get the same result
with print(). Make sure that your ptn() method does the right thing when
called in list (!) context.

Here's some code to show that it works as expected:

     use strict;

     package Wobble;
     sub new { bless {}, shift; }
     sub ptn { return "wobble!" }

     package main;
     use Log::Log4perl qw(:levels get_logger);
     Log::Log4perl->easy_init($DEBUG);

     my $logger = get_logger();

     my $wobble = Wobble->new();
     $logger->info("return of ptn: ", $wobble->ptn());


-- Mike

Mike Schilli
m...@pe...

[log4perl-devel] DBIC Object not interpreted

[Steve <st...@ma...>]

Where $newsub is an object, the following fails to work as I expected it to:

$logger->info("Created sub->", $newsub->ptn);

Since my log is a text file, this yields the following line in the file:
2010/05/10 16:38:59 INFO> cmsIMsubs-S.pl:176 main::getSubs - Created 
sub->CMS::Schema::Result::Subscription=HASH(0x96b9164)->ptn

In case it's not obvious, I'd like to log the phone number, not what 
type of object I'm looking at.

TIA

Re: [log4perl-devel] Log::Log4perl conundrum

[Mike S. <m...@pe...>]

Andrew Whatson writes:

> How would one create a logging setup that will log:
>  - all TRACE messages to a log file
> - all INFO messages to the screen

Hi Andrew,

I could have sworn I answered this question a week ago, but the message
doesn't seem to have made it back to the list, so here it is:

The log4perl FAQ describes this scenario in

"How can I send errors to the screen, and debug messages to a file?"

http://search.cpan.org/dist/Log-Log4perl/lib/Log/Log4perl/FAQ.pm#How_can_I_send_errors_to_the_screen,_and_debug_messages_to_a_file?

-- Mike

Mike Schilli
m...@pe...

Re: [log4perl-devel] UTF-8, Threads and Syswrite

[<pa...@ae...>]

Hi Mike,

 

Thanks for the reply.

 

Sorry I should have mentioned this: My production system is perl 5.8.8.
I've had other people try the code (you can do it without log4perl just
using 

STDOUT even) and it seems to work fine in 5.10.  So this might just be
something that was improved with later versions of perl.

 

"use utf8" doesn't seem to change anything for my perl interpreter, but
regardless it won't affect the live code - the data is being sourced
from a web service, and I believe it is being correctly flagged as utf8
- though I will double check that. 

 

I will try some more up to date interpreters and see if that helps
things.

 

-Pat

 

________________________________

From: Mike Schilli [mailto:m...@pe...]
Sent: Wed 4/21/2010 12:06 AM
To: Pat Lynam
Cc: log...@li...
Subject: Re: [log4perl-devel] UTF-8, Threads and Syswrite

On Tue, 20 Apr 2010, pa...@ae... wrote:

> Everything works,  because the utf8 flag is set everything is fine.
> However, as soon as we start spawning threads...

Works for me also, only thing I changed was to add

     use utf8;

at the beginning as you're writing code in UTF8. Without it, I end up
with doubly-encoded characters in the log file (no warning, though).

Tested with perl-5.10.0 and perl-5.10.1.

-- Mike

Mike Schilli
m...@pe...

>
>
>
> use threads;
>
> use threads::shared;
>
> use Log::Log4perl qw(get_logger);
>
> Log::Log4perl->init_and_watch("log.conf", 60);
>
>
>
> my $char = "\x{30DE}\x{30A4}\x{30AF}";
>
>
>
> #my $a = threads->create(\&foo, 'Somecategory');
>
> #$a->join();
>
>
>
> foo('Somecategory');
>
>
>
> sub foo {
>
>        my $cat = shift;
>
>        my $log = get_logger($cat);
>
>
>
>        $log->info("character [$char]");
>
> }
>
>
>
> I get "Thread 1 terminated abnormally: Wide character in syswrite at
> /usr/lib/perl5/site_perl/5.8.8/Log/Log4perl/Appender/File.pm line
242."
>
>
>
> This seems to be a case where the file handle is losing the utf8
> property, and so it must be set again on the handle.  I'm not sure why
> exactly that happens and am still investigating but this seems to fix
> it:
>
>
>
> Adding to Log4perl/Appender/File.pm on line 242 above the syswrite:
>
>
>
> If (defined $self->{utf8}) {
>
>        binmode($fh, ":utf8");
>
> }
>
>
>
> Note that I have done testing on other file handles and this appears
to
> affect everything.  Possibly I am doing something wrong and need to
make
> Log4Perl more aware of threads?  The get_logger calls within the
> subroutine are there to simulate the usage of my program, and are
> possibly not the ideal use?
>
>
>
> Please let me know, great tool otherwise!
>
>
>
> -Pat
>
>
>
>
>
>

Re: [log4perl-devel] UTF-8, Threads and Syswrite

[Mike S. <m...@pe...>]

On Tue, 20 Apr 2010, pa...@ae... wrote:

> Everything works,  because the utf8 flag is set everything is fine.
> However, as soon as we start spawning threads...

Works for me also, only thing I changed was to add

     use utf8;

at the beginning as you're writing code in UTF8. Without it, I end up
with doubly-encoded characters in the log file (no warning, though).

Tested with perl-5.10.0 and perl-5.10.1.

-- Mike

Mike Schilli
m...@pe...

>
>
>
> use threads;
>
> use threads::shared;
>
> use Log::Log4perl qw(get_logger);
>
> Log::Log4perl->init_and_watch("log.conf", 60);
>
>
>
> my $char = "\x{30DE}\x{30A4}\x{30AF}";
>
>
>
> #my $a = threads->create(\&foo, 'Somecategory');
>
> #$a->join();
>
>
>
> foo('Somecategory');
>
>
>
> sub foo {
>
>        my $cat = shift;
>
>        my $log = get_logger($cat);
>
>
>
>        $log->info("character [$char]");
>
> }
>
>
>
> I get "Thread 1 terminated abnormally: Wide character in syswrite at
> /usr/lib/perl5/site_perl/5.8.8/Log/Log4perl/Appender/File.pm line 242."
>
>
>
> This seems to be a case where the file handle is losing the utf8
> property, and so it must be set again on the handle.  I'm not sure why
> exactly that happens and am still investigating but this seems to fix
> it:
>
>
>
> Adding to Log4perl/Appender/File.pm on line 242 above the syswrite:
>
>
>
> If (defined $self->{utf8}) {
>
>        binmode($fh, ":utf8");
>
> }
>
>
>
> Note that I have done testing on other file handles and this appears to
> affect everything.  Possibly I am doing something wrong and need to make
> Log4Perl more aware of threads?  The get_logger calls within the
> subroutine are there to simulate the usage of my program, and are
> possibly not the ideal use?
>
>
>
> Please let me know, great tool otherwise!
>
>
>
> -Pat
>
>
>
>
>
>

[log4perl-devel] Log::Log4perl conundrum

[Andrew W. <wh...@gm...>]

Hi list,

I've been using Log::Log4perl in my application for a few months now and quite
appreciate its flexibility.  There is one simple issue that I can't quite
work out, however...

How would one create a logging setup that will log:
 - all TRACE messages to a log file
 - all INFO messages to the screen

My understanding is that these would need to be appenders on the root logger
in order to catch all messages, however there can only be one log level set
for the logger.  There's no way that I can see to set the log level per
appender, or to have two root loggers with different log levels.

I'm sure there must be some way to do it!

Thanks in advance,
Andrew