Bitmasked loggers

[Ceki Gülcü <ce...@qos.ch>]

Greetings,

In response to Joseph Ottinger's article:

  http://www.sys-con.com/java/article.cfm?id=1714

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
idea.

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.setLevel(Level.DEBUG);
  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
wrong.


--
Ceki




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bitmasked loggers

[Ceki Gülcü <ce...@qos.ch>]

At 07:43 05.12.2002 -0500, Joseph Ottinger wrote:
>Ceki, I don't think I submitted an indea for bitmasked logging to Log4J,
>although I may have - it's not really an idea I can claim as my own, as
>shown by your own considerations.

OK, my mistake.

>I'm aware that Log4J can do something similar to a bitmasked logger. I use
>Log4J daily; it's a good product. (I bought your book!)

Thank you.

>I think it's
>typically more appropriate to increase the *vertical* space (by providing
>more detail in logging capability for a given logger) than it is to
>increase the *horizontal* space (by creating new categories and loggers,
>which involves a lot of object creation).

I must admit that I haven't given much thought to enhancing the
vertical space. I tend to view levels and loggers as just
dimensions. Moreover, thought-experiments show that adding new
dimensions can be both economical and useful. The major problem is to
keep it simple enough to explain to a new log4j user.

>I was using Log4J as an example of where the JCP needed to improve things,
>instead of using them as they were. I realise that's often counter to the
>concept of the JCP itself (which is to take existing projects, allow the
>interested parties to improve them, and integrate them) but I think that
>runs counter to the overall improvement of Java.

I think Sun wasted much of its credibility by pushing not-so-standard
standards. People will eventually wake up to this fact.  Although you
probably did not make any new friends at Sun, your article will help
people come to that realization. Thanks for having had the courage to
write it.

BTW, you might find the following article relevant:

(WHY DUMB THINGS HAPPEN TO SMART COMPANIES)
  http://www.polarismktg.com/comment1.htm


--
Ceki



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Bitmasked loggers

[Joseph Ottinger <jo...@enigmastation.com>]

Ceki, I don't think I submitted an indea for bitmasked logging to Log4J,
although I may have - it's not really an idea I can claim as my own, as
shown by your own considerations.

I'm aware that Log4J can do something similar to a bitmasked logger. I use
Log4J daily; it's a good product. (I bought your book!) I think it's
typically more appropriate to increase the *vertical* space (by providing
more detail in logging capability for a given logger) than it is to
increase the *horizontal* space (by creating new categories and loggers,
which involves a lot of object creation).

I was using Log4J as an example of where the JCP needed to improve things,
instead of using them as they were. I realise that's often counter to the
concept of the JCP itself (which is to take existing projects, allow the
interested parties to improve them, and integrate them) but I think that
runs counter to the overall improvement of Java.

On Thu, 5 Dec 2002, Ceki [iso-8859-1] G�lc� wrote:

>
> Greetings,
>
> In response to Joseph Ottinger's article:
>
>   http://www.sys-con.com/java/article.cfm?id=1714
>
> 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
> idea.
>
> 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.setLevel(Level.DEBUG);
>   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
> wrong.
>
>
> --
> Ceki
>
>
>

---------------------------------------------------------
Joseph B. Ottinger                 joeo@enigmastation.com
http://enigmastation.com                    IT Consultant

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>