Bug #39085 for Log-Log4perl: is_info() etc seem to give wrong result

Mon Sep 08 08:06:12 2008 Allen.Conway [...] atosorigin.com - Ticket created

Subject:	is_info() etc seem to give wrong result
Date:	Mon, 8 Sep 2008 14:05:47 +0200
To:	"bug-Log-Log4perl [...] rt.cpan.org" <bug-Log-Log4perl [...] rt.cpan.org>
From:	Conway Allen <Allen.Conway [...] atosorigin.com>

It seems to me that the is_ routines only take into account the - I'm not sure what you call it - the threshold you specify on the log4perl.category statement at the top of the log configuration and they don't take into account the thresholds defined for the appenders that have been defined, i.e. if you say log4perl.category = TRACE, A1 and in A1 you say log4perl.appender.A1.Threshold = ERROR you find that is_trace(), is_debug() and is_info() all return true. I would expect them to return false. platform: Linux 2.6.26 perl: 5.10.0 Log::Log4perl 1.17 best regards Show quoted text

________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Tue Sep 09 02:00:52 2008 MSCHILLI [...] cpan.org - Correspondence added

On Mon Sep 08 08:06:12 2008, Allen.Conway@atosorigin.com wrote: Show quoted text

> It seems to me that the is_ routines only take into account the - I'm > not sure what you call it - the threshold you specify on the > log4perl.category statement ... and > they don't take into account the thresholds defined for the > appenders that have been defined

That's correct, is_debug() only checks if the loggers permit a DEBUG message to pass through. It does not check appender thresholds (or filters for that matter). The reason for this is that you could have multiple appenders with different thresholds and while one might log the message, another appender won't. There would be several ways of interpreting this: Do you want 'true' if a) one appender logs the message b) all appenders log the message or c) a specific appender logs the message? Adding filters to the mix you could have messages suppressed on content and that's impossible to detect by is_debug(), because it doesn't have the message. Since it's very difficult to find consensus here, Log4perl (and its archetype log4j) just punt and simply check the loggers only -- although this doesn't necessarily mean that a message gets logged. Sorry! :) -- Mike

Tue Sep 09 02:00:54 2008 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 09 02:00:56 2008 MSCHILLI [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Sep 09 02:28:06 2008 Allen.Conway [...] atosorigin.com - Correspondence added

Subject:	RE: [rt.cpan.org #39085] is_info() etc seem to give wrong result
Date:	Tue, 9 Sep 2008 08:27:50 +0200
To:	"bug-Log-Log4perl [...] rt.cpan.org" <bug-Log-Log4perl [...] rt.cpan.org>
From:	Conway Allen <Allen.Conway [...] atosorigin.com>

Michael, Thanks for your reply. In so far as the is_xxx() routines are there to let you know whether it's worthwhile or not to format a message I would think that returning true when the message isn't going to end up being logged is not of much use. So I expected the routines to check that there was at least one appender that would accept the message. However, there's the matter of filters... Never having used filters my expectations didn't take them on board!! I see the problem - if it would take half an hour to decide whether a message will make it through the threshold barriers and the filters then the usefulness of these routines goes out the window. What can I say? Do whatever you like (but then you're bright enough to know that anyway!) but it would be good if you could make it clearer in the documentation what these routines really do. I just wonder if we get the same behaviour in Log4j (that I haven't much used) and Log4cxx (that I have used quite a lot) - I'm suddenly a little worried that my C++ programs spend a lot of time formatting messages that never get logged! Allen PS Thanks for the "sorry" but there was no need! Oh and thank's for the module - it's very useful. BTW I wonder if it would be possible and useful for the module to be case insensitive with regard to threshold names? Show quoted text

-----Original Message----- From: Michael_Schilli via RT [mailto:bug-Log-Log4perl@rt.cpan.org] Sent: Tuesday, September 09, 2008 8:01 AM To: Conway Allen Subject: [rt.cpan.org #39085] is_info() etc seem to give wrong result <URL: http://rt.cpan.org/Ticket/Display.html?id=39085 > On Mon Sep 08 08:06:12 2008, Allen.Conway@atosorigin.com wrote:

> It seems to me that the is_ routines only take into account the - I'm > not sure what you call it - the threshold you specify on the > log4perl.category statement ... and > they don't take into account the thresholds defined for the > appenders that have been defined

That's correct, is_debug() only checks if the loggers permit a DEBUG message to pass through. It does not check appender thresholds (or filters for that matter). The reason for this is that you could have multiple appenders with different thresholds and while one might log the message, another appender won't. There would be several ways of interpreting this: Do you want 'true' if a) one appender logs the message b) all appenders log the message or c) a specific appender logs the message? Adding filters to the mix you could have messages suppressed on content and that's impossible to detect by is_debug(), because it doesn't have the message. Since it's very difficult to find consensus here, Log4perl (and its archetype log4j) just punt and simply check the loggers only -- although this doesn't necessarily mean that a message gets logged. Sorry! :) -- Mike Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Tue Sep 09 02:28:08 2008 The RT System itself - Status changed from 'resolved' to 'open'

Fri Sep 19 00:31:23 2008 MSCHILLI [...] cpan.org - Correspondence added

I'm pretty sure that all other log4X implementations are doing the same thing. I've added the following explanation to the docs: Show quoted text

>Note that even if one of the methods above returns true, it doesn't >necessarily mean that the message will actually get logged. What >is_debug() checks is that the logger used is configured to let a message >of the given priority (DEBUG) through. But after this check, Log4perl >will eventually apply custom filters and forward the message to one or >more appenders. None of this gets checked by is_xxx(), for the simple >reason that it's impossible to know what a custom filter does with a >message without having the actual message or what an appender does to a >message without actually having it log it.

I hope that that will clarify the issue, thanks for your note! -- Mike

Fri Sep 19 00:32:03 2008 MSCHILLI [...] cpan.org - Status changed from 'open' to 'resolved'