+1
However, isn't there a potential problem with the fact that many servers include logj4 in the classpath by default? I just had some experience with Weblogic's ridiculous classloading behavior (of course, the real issue was with commons-logging, but I'll take a short rest on bashing that, ummm...., "product" today) where I was forced to put Log4j, commons-logging, and a bunch of other jars in the server's classpath and remove them from WEB-INF/lib of the webapp, otherwise Struts would die a nasty death. The point is, if one starts using logger.trace("blah blah blah") in their applications and tries to deploy on Weblogic where they can't include log4j in WEB-INF/lib and have no control over what version the server includes, their app won't work if the server includes Log4j pre 1.3.
On the other hand, one could make the same argument for any other new features in 1.3 such as domains, the new repository selector implementations, using Joran for configuration, etc. As long as the community is willing to live with the fact that certain server implementations (read "Weblogic") provide crappy classloading behavior and will have to be worked around in order to take advantage of any new logj4 features, I'm all for the change if the community wants it as it won't hurt anything any more than any other new feature would.
Jake
At 04:30 PM 3/12/2004 +0100, you wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
