ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: AspectJ logging was [Re: Purpose of FileUtils.close(...)]
Date Thu, 20 Jan 2005 10:03:34 GMT
Kev Jackson wrote:
>> Another thought:  We could create an AntThread class
>> to tie a Thread to a Project.  Most places that
>> currently use Thread constructors would use the same
>> AntThread constructor.  The top-level AntThread could
>> be constructed with an explicit Project; others could
>> inherit the Project from the AntThread along whose
>> path of execution the child AntThreads were created. Have I missed 
>> something earth-shattering, or does this
>> sound like something that could help us with our
>> logging on classes, such as those in the util package,
>> that do not extend ProjectComponent?
> I've been thinking about the logging within Ant for a while now, and 
> whilst people are suggesting solutions, here's my take.
> - Log4j works perfectly well for logging, so long as the developer puts 
> the call in at the appropriate place.
> - FileUtils.close() seems to swallow problems that occur when closing files
> - For a certain class of problems (out of disk space), it's very 
> difficult to track down with the current behaviour
> - adding logging statements to the code makes the code larger and less 
> clear
> I propose using AspectJ as a solution to manually adding in the logging 
> statements.
> I've been implementing this in the project I'm working on here and it's 
> very elegant.  One aspect for logging and place the call to Log4j inside 
> the aspect, remove all the logging calls from the code (reducing code 
> size) and dependency on Log4j in *many* classes.
> Use before advice and whenever the advice matches, AspectJ will 
> introduce the logging statement at runtime.
> something like this...
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> public aspect Logger {
>    final Log logger = LogFactory.getLog(getClass());
>      pointcut exceptions() : execution(* 
>        before() : exceptions() {
>"[ "+ thisJoinPointStaticPart.getSignature()+" ]");
>    }
> }
> Problems:
> - dependency on yet another third-party jar (compile and run-time, 
> although the runtime jar is only 41kb)
> - large number of packages, have to create a complicated pointcut 
> hiearchy to capture them all
> - licensing? AspectJ is CPL, not ASF code
> - could break bc in unforseen ways given the amount of classes that 
> would be affected
> - performance hit (although AspectJ has a very low hit (in the order of 
> nano-seconds))
> I still think that it's the best solution AspectJ+Log4j work like a 
> dream together.  If not for the current version of Ant, perhaps for 
> future use.

I havent used aspectJ, so cannot comment there.

I am reluctant to make a new JAR mandatory, plus there is the bootstrap 
problem: ant likes to be at the bottom of the food chain with nothing 
but an XML parser and the rest of the JDK as dependencies.

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

View raw message