ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Ant log statements being created even when not used
Date Mon, 25 Sep 2006 14:49:29 GMT
Dominique Devienne wrote:
>> To account for long lived listener, we would also need a method on
>> project to reset the cache of the current level, which would be
>> initialized any time a new listener is added. --DD
> The use case for this would be a hypothetical CruiseControl (for
> example) listener whose log level could be dynamically changed thru a
> web app, in the middle of the running of a long build.
> Or a listener whose level changes based on the events it received, to
> log at a lower levels a particular target or task for example.

FWIW, our work logging framework that slots behind commons logging does 
support dynamic log level changing. As long as the code that pumps out 
messages doesnt cache the log level there's nothing to stop you logging 
at different levels. Right now, even though ant is nominally flexible, 
that flexiblity doesnt get used, various tasks have a 'verbose' override 
to do their own log levels, and there is extra cpu time in creating log 
output that is discarded.

+1 to -at-some-point-in-the-future- having a way to query log levels

+ 1 to mapping 1:1 with commons-logging/log4j/java1.4 tracing and 
implementing the relevant bridge classes.

+ 1 to letting the end users tune the log in a build, somehow

+1 for moving all tasks to doing more efficient queries. Remember that 
you only need to check for an isDebugEnabled if you are doing string 
concatenation or toString work; log("fact") is faster than 
if(log.isInfoEnabled()) log(fact) because you skip the extra method call.

-1 for doing this in the ant1.7 timeframe.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message