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]
