logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wolf Siberski" <siber...@learninglab.de>
Subject RE: [VOTE] Adding the TRACE level
Date Mon, 15 Mar 2004 09:02:05 GMT
+1

IMHO adding the TRACE level imposes no burden on the current or
future log4j development. It's just a trivial extension which
doesn't add any new complexity or blocks future changes.

If users want a feature which log4j can give them nearly
for free, why not do it? Even if it may not be the optimal
approach to logging.

--Wolf



> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch] 
> Sent: Friday, March 12, 2004 5:30 PM
> To: Log4J Developers List
> 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: 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


Mime
View raw message