ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject Re: [DISC] Aspect implementation
Date Fri, 01 Jun 2001 14:19:03 GMT
For those who are unfamiliar with the concept of aspects, you can try the
following links which discuss AspectJ, an implementation of aspects for

I'd also like to raise a further point. Currently I am only triggering an
aspect when there is some attribute value that use's the aspect's prefix in
its namespace. However, I can see some value for aspects invoked regardless
of the presence of such attributes. A debugging aspect might be an example.
So, we may need some way of defining pointcuts to apply aspects.


----- Original Message -----
From: "Conor MacNeill" <>
To: <>
Sent: Friday, June 01, 2001 11:30 PM
Subject: [DISC] Aspect implementation

> I'd like to initiate a discussion of aspect implementation. I think we
> some level of agreement that we will have aspects but no real clear idea
> about how they will look. I have done an initial implementation of an
> aspect in mutant. It handles the "id" attribute in something like this
>     <fileset ant:id="std.fileset"
>              dir="jakarta-ant/proposal/mutant">
>     </fileset>
> The "ant:" triggers the aspect The aspect is defined in the antlib.xml
> this statement
>    <aspect prefix="ant"
> classname="org.apache.ant.component.core.AntAspectHandler"/>
> Note that the id attribute in Ant1 is an implicit aspect, as it is
> by the ProjectHelper.
> The AspectHandler interface currently looks like this
> public interface AspectHandler {
>     void setAspectContext(ExecutionContext context);
>     void beforeConfigElement(Object element) throws ExecutionException ;
>     void afterConfigElement(Object element) throws ExecutionException ;
> }
> The beforeXXX and afterXXX methods in the interface represent the join
> points of the ant execution. There will be more added, especially dealing
> with task execution, perhaps
> void beforeExecuteTask
> void aroundExecuteTask
> void afterExecuteTask
> Now, the question I really am concerned with here is the lifetime of the
> aspect instance. I wanted to use introspection (via the mutant equivalent
> of IntrospectionHelper), to configure the attributes of the aspect. So in
> the above aspect, I provide a setId method to capture the value of the
> "ant:id" attribute.
> So, at the moment, I am doing the following
> 1. create the aspect handler instance
> 2. call beforeConfigElement
> 3. configure the element (configuring involves passing the values from
> project model (proxy) to the execution element)
> 4. call afterConfigElement
> 5. throw away aspect handler instance.
> For task execution, I would create a separate instance of the same aspect
> handler and perform a similar procedure. I'm wondering if this is the
> way. I see other alternatives
> 1. Associate an aspect handler instance with each element and invoking
> appropriate operation on this aspect when the element goes through the
> point.
> 2. Have a single instance of the aspect handler handling all elements
> invoke that aspect.
> 3. What I have currently with mutant, a separate instance for each joint
> point group.
> 1. Seems OK, I guess - can be configured when the associated element is
> configured.
> 2. may have difficulties with configuration and multithreading.
> 3. implies a stateless aspect (or one which stores and finds its state
> each join point group).
> Another issue for aspects will be how to guarantee they are invoked for
> tasks which are controlled by a TaskContainer task. Hmm.
> Thoughts?
> Conor

View raw message