ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject [DISC] Aspect implementation
Date Fri, 01 Jun 2001 13:30:57 GMT
I'd like to initiate a discussion of aspect implementation. I think we have
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"

The "ant:" triggers the aspect The aspect is defined in the antlib.xml with
this statement
   <aspect prefix="ant"

Note that the id attribute in Ant1 is an implicit aspect, as it is handled
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 the
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 right
way. I see other alternatives

1. Associate an aspect handler instance with each element and invoking the
appropriate operation on this aspect when the element goes through the join
2. Have a single instance of the aspect handler handling all elements which
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
2. may have difficulties with configuration and multithreading.
3. implies a stateless aspect (or one which stores and finds its state for
each join point group).

Another issue for aspects will be how to guarantee they are invoked for the
tasks which are controlled by a TaskContainer task. Hmm.



View raw message