AspectJ logging was [Re: Purpose of FileUtils.close(...)]

[Kev Jackson <ke...@it.fts-vn.com>]

>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(* 
org.apache.tools.ant.*Exception(..));
     
    before() : exceptions() {
         logger.info("[ "+ 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.

Thoughts/ideas/rebuttals and out-right criticism welcome!

Kev


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: AspectJ logging was [Re: Purpose of FileUtils.close(...)]

[Steve Loughran <st...@apache.org>]

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(* 
> org.apache.tools.ant.*Exception(..));
>        before() : exceptions() {
>         logger.info("[ "+ 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org