logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Bitmasked loggers
Date Thu, 05 Dec 2002 11:29:54 GMT


In response to Joseph Ottinger's article:


I made the following comments:

If I am not mistaken, Joseph has already submitted his idea for
bitmasked loggers to the log4j-user mailing list. It was probably
summarily brushed aside because bitmasked loggers (as I understand
them) still rely heavily on levels. (If that was indeed the case, I
apologize.) Let me explain why imho bitmasked loggers are not a good

The central problem in logging is the proper categorization of logging
statements. Log4j offers two dimensions of categorization: the logger
space and the level space (i.e. the set of levels). Thus, each logging
statement is characterized by two parameters, the logger of the
statement and the level of the statement. For example, when we write:

  Logger l = Logger.getLogger("wombat");
  l.info("Sun is losing its way.");

the logging statement is defined by its logger 'l' and its level
'INFO'. As far as the logger 'l' is concerned the statement is enabled
because DEBUG <= INFO.

Bitmasked loggers enhance the logic of logger/level interaction,
instead of integer comparison between levels, we would have bit masked
comparisons and that would allow more possibilities.

However, instead of enriching the logical interactions between loggers
and levels, we could increase the number of dimensions of the logging
space. More dimensions allow for far richer interactions. Surprisingly
those interactions are more tractable as well. The hard part is to
compose the interactions in a way that make sense without being too
costly in computating power. The next version of log4j, i.e. 1.3,
promises to do just that.

By the way, I very much enjoyed the article. I really wish Joseph were


To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

View raw message