ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: testing for verbose mode
Date Sat, 10 Jul 2004 12:02:55 GMT
Wascally Wabbit wrote:
> At 11:17 AM 7/9/2004, you wrote:
> 
>> 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)
> 
> 
> 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...

1. There isnt going to be a 'big rewrite Ant 2', just gradual evolution.

2. We are at the bottom of the food chain. We cannot introduce 
dependencies in the core on projects that need ant to build, or you 
cannot bootstrap the gump. (http://gump.apache.org).

3. What we can do is have an interface with a 1:1 mapping with

> 
> 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.

yes. I've just attached something to do that for commons-logging. One 
problem I have here is forcing a particular instance of a logger into a 
program. How did you manage that?

Also, I think there may be performance benefits in core ant if we only 
issue debug and verbose logs when debug and verbose are enabled; 
instrumentation is never free & the overhead of toString() and string 
concatenate operations may be tangible. But we cannot test that, yet.


-steve

Mime
View raw message