log4perl
log4perl copied to clipboard
logconfess logs stacktrace on multiple lines
Using logconfess() ends in logging every part of the stacktrace in a single line:
2017/09/15 09:09:05 ich sterbe! at test_logfatal.pl.pm line 13.
2017/09/15 09:09:05 class1::foo("class1") called at test_logfatal.pl.pm line 21
2017/09/15 09:09:05 class2::foo("class2") called at test_logfatal.pl.pm line 28
2017/09/15 09:09:05 class3::foo("class3") called at test_logfatal.pl.pm line 39
2017/09/15 09:09:05 eval {...} called at test_logfatal.pl.pm line 39
Here is the example code:
use strict;
use warnings;
package class1;
use Log::Log4perl qw(get_logger);
sub foo() {
my $logger = get_logger();
$logger->logconfess("ich sterbe!");
}
package class2;
sub foo() { class1->foo(); }
package class3;
sub foo() { class2->foo(); }
package main;
use Carp;
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init({level => Log::Log4perl::Level->INFO_INT});
my $logger = get_logger();
eval { class3->foo() };
if ($@) {
...
}
Using an email-appender this behaviour results in sending one email for every line of the stacktrace. Not nice.
How can I force logconfess to write one logmessage with stacktrace instead of multiple lines? At the end I want to get only one email for the whole logmessage.
Is there anybody out there who can help me?
May I ask why you'd use logconfess
in combination with an email-appender?
Of course you may ask :-) But in the meantime there are some years gone ... I'm not sure about the code from this time and I do not have access to it yet. I belive I would get an information about every dying process with background information.
But, generally, shouldn't the code be independent from the kind of the appender? And imho it's not usual to write stacktraces in multiple logmessages at all.
I don't disagree in principle, but "confess" is a Carp function that expressly adds a stacktrace. There isn't really a good way to have one conceptual message that's composed of multiple loglines (at least, not yet - perhaps if one provided an array-ref not a string? I'm open to backwards-compatible ideas).
In the meantime, if the real problem is that the email handler should wait a few moments and bundle up messages, then that's a separate problem that should be handled separately.
Fundamentally, unless the array-ref idea is workable, and implemented, this issue is a fundamental design one that causes very little pain normally, and should therefore be closed.