+1 If a good number of folks in the user community have requested this feature, let's give it to them.
Hopefully this will address concerns that there aren't enough built-in Levels.
I think once we all have a better understanding of domains (and support for Properties
at the event-creation stage instead of just Receivers and Appenders), folks will take
advantage of the flexibility, and Levels will remain a useful but general way of
characterizing logging events.
Scott
----- 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]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
