Conor MacNeill wrote:
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.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.
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)
Isn't Ant2 going to address the logging issue "holistically" by using an established logging framework like log4j or commons logging as the backbone for the default build logger implementations? If so, is it worth the effort to create new (patch) APIs that will introduce more architecture/implementation constraint pressure on Ant2? Just a question...
BTW, I have already wrapped Ant for Log4J/J2SE using the current 1.6x build listener mechanism. Like you said, it allows me to run (externally controlled) log-instrumented *script* under Ant efficiently while leaving the Ant logging mechanism as-is. However, it's still not possible to make "is this level enabled" from within task Java code.
The Wabbit
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
