Bug #73462 for Log-Log4perl: logwarn() should warn() unconditionally

Fri Dec 23 17:34:53 2011 MSCHILLI [...] cpan.org - Ticket created

Subject:

logwarn() should warn() unconditionally

There are two requests (by Martin J. Evans and Christopher Mckay) to change the behavior of logwarn() so that it will a) warn() unconditionally and b) issue a WARN-level message to log4perl, which will then be logged conditionally. The current implementation suppresses the warn() call if the Log4perl level requires the message to be suppressed in Log4perl. This leads to unexpected results, because changing warn() in Perl code to $logger->logwarn() changes the program's behavior when Log4perl turns logging off.

Fri Dec 23 17:36:50 2011 MSCHILLI [...] cpan.org - Correspondence added

Here's Martin's comments: So simply substituting warn with logwarn can change the way your program works. It is not for me to tell you how Log::Log4perl should work but I find this behaviour unacceptable as my program will behave differently depending on the log level. Logging should be logging, not changing the way my program runs. Example: $ perl -le '$SIG{__WARN__} = sub {CORE::die "Warning:\n", @_, "\n"}; use Log::Log4perl qw(get_logger); my $lh = get_logger("BET::Data::Remove");warn("fred"); print "ok";' Warning: fred at -e line 1. Change the warn to logwarn: $ perl -le '$SIG{__WARN__} = sub {CORE::die "Warning:\n", @_, "\n"}; use Log::Log4perl qw(get_logger); my $lh = get_logger("BET::Data::Remove");$lh->logwarn("fred"); print "ok"; ok Would you consider changing this? If not, I would be most grateful if you could you point me at the place where I could change this behaviour or tell my how I could override it.

Fri Dec 23 17:36:51 2011 MSCHILLI [...] cpan.org - Status changed from 'new' to 'open'

Fri Dec 23 17:38:39 2011 MSCHILLI [...] cpan.org - Correspondence added

And here are Chris' comments: So I came across this when I tried to use log4perl without initializing it (I wanted warnings and deaths, and when the modules user was using log4perl it all to be logged as well). The logdie and associated methods all die regardless of log level but the warn versions all require log4perl to be configured to log the message of that level before it will issue the warn statement. This seems wrong to me as I thought the intention of these methods was was to log your warnings as opposed to warn your log messages. Originally I was just going to fork and put in a pull request for this and let that be accepted or rejected, but after I started working on it I found that t/024WarnDieCarp.t explicitly tests for the warnings not being made when the log level isn't high enough, so now I'm thinking this is intended behavior and just a really odd design decision. So I'm keen to have a version of logwarn that warns regardless of log levels or initialization either by repairing the existing methods or implementing some new methods. I'm eager to do the work for either solution if you guys are happy to see either implemented. So let me know whether either of these is ok or if I'm just confused.

Fri Dec 23 17:41:18 2011 MSCHILLI [...] cpan.org - Correspondence added

Link to the github issue tracker: https://github.com/mschilli/log4perl/issues/12

Fri Dec 23 19:54:49 2011 MSCHILLI [...] cpan.org - Correspondence added

Fixed: https://github.com/mschilli/log4perl/commit/7d7fbbb45254d6c903f5b3cb91d7 059c8267c40d

Fri Dec 23 19:54:49 2011 MSCHILLI [...] cpan.org - Status changed from 'open' to 'resolved'