+0
I've done the custom TRACE level as an argument to Logger.log. (I was the
one that wrote the Wiki page...) As noted, modern IDEs automate the task.
However, over time my team and I stopped using TRACE because in use we
didn't really see a need for it. We thought we did, but we were wrong.
Doesn't mean that other people don't need that, though.
While domains are definitely cool, the fact is that people think in terms of
levels. So just because domains render it obsolete doesn't make a TRACE
level invalid, just redundant.
TRACE is common enough that it just "looks bad" that log4j doesn't have it.
So while I don't see a real need for it, I am slightly in favor of it
primarily for reasons of helping the way log4j is perceived -- justified or
not.
-Jim Moore
----- Original Message -----
From: "Ceki G�lc�" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Friday, March 12, 2004 10: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 the
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:
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceLevel
Although typing in this method call is slightly longer than typing the
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
