logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <Paul.Sm...@lawlex.com.au>
Subject RE: [VOTE] Adding the TRACE level
Date Sat, 13 Mar 2004 08:54:28 GMT

I don't see TRACE as a 'useful' addition so it doesn't deserve a +1.  I have
to say a Here-Here to everything Jim Moore said.  _I_ don't think it is
useful, but a fair number of other people do think do think it's useful (for
now maybe).

My Vote is purely for the benefit of perception of log4j.  I cannot see it
hurting Log4j at all;  I can't see it pinning us into a development/design
corner; and I can't see myself using it.  

log4j doesn't benefit from TRACE, but maybe the log4j community might.
Given the lack of impact on the rest of the code, I think we should just do
it for those who want it, and just move on.

And if adding TRACE does end up causing us pain, I promise I will send any
-1 voters some premium Australian beer/wine (note: Foster's beer is crap,
all Australian's consider it evil).

(you can consider me a +1 if the 0.5 screws things up).


Paul Smith
-----Original Message-----
From: Ceki Gülcü
To: Log4J Developers List
Sent: 3/13/04 2:30 AM
Subject: [VOTE] Adding the TRACE level

Hi All,

The issue has been discussed several times in the log4j mailing lists
and great many users have asked for it. Consequently, here is a formal
vote to include the TRACE level.

[ ] +1, Yes, the TRACE would be a useful addition
[ ]  0, I don't care
[ ] -1, No, TRACE should not be included

I would like to vote -1 due to the following arguments:

- Many people use INFO and DEBUG for development, eliminating the need
   for TRACE. One uses DEBUG to output chatty information and INFO to
   output an overview the application's progress.

- The next version of log4j will introduce the concept of domains
   allowing developers to log by multiple criteria, thus creating a much
   more powerful way of categorizing (i.e. classifying) logging
   statements, thus dispensing with the need to use various new levels
   (e.g. the trace level) to express logging/filtering criteria. With
   introduction of domains the trace level will look like what it really
   is, a common but nonetheless a lame hack.

- It is possible to wrap the Logger class and extend the Level class to
   include support for the trace level.

- Moreover, The generic log() method in the Logger class takes in a
   Level as its first parameter. This allows the developer to log at
   any level, including the trace level. For example:

        Logger logger = Logger.getLogger("some.logger.name");
        logger.log(XLevel.TRACE, "some message");

   where [XLevel] class extends the Level class by adding the trace
   level. There is a section about in the FAQ as well:

   Although typing in this method call is slightly longer than typing
   usual printing methods such as logger.debug("message") or
   logger.info("message"), modern IDEs can easily automate the process.

Given that code changes require lazy consensus, this veto kills the
vote right in the bud. Note this is the usual procedure for reaching a
decision at Apache. At the same time, it does not seem right to me
that a single individual should be able to overrule everyone else,
especially if that person happens to be me.

Maybe we should change the Logging Services bylaws to demand a 2/3
majority or just a simple majority instead of lazy consensus for code
changes. What do you guys think?

Ceki Gülcü
      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message