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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
