Conor MacNeill wrote:
It you can decide not to issue messages, you can decide to change the behavior of your task in a more radical fashion. But nevermind this point.
Still if we want to have such functionality what we would need is an API in project to check for current "logging level of interest" that internally will consult ALL BuildLogger2 instances and give the aggregated answer. Such a system will work in the presence of <record/> loggers.
That would be BuildListener2. There's a difference. I still think there is value in being able to control the logger. Being able to control the threshold in the logger (without affecting events sent to other listeners) would be useful for script debugging. I've always found <record> to be somewhat cumbersome.
I'd like to do a good wrapper of commons logging around ant logger that took the aggregate log level and forwarded it. This would make it easier to run highly log-instrumented code under Ant efficiently and yet integrated with Ant's logging (e.g axis-wsdl2java)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
