Return-Path: 
 <ant-dev-return-14269-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 85870 invoked by uid 500); 1 Jun 2001 14:14:59 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 85858 invoked from network); 1 Jun 2001 14:14:57 -0000
Message-ID: <009f01c0eaa5$d6c3e640$60c4223f@cognetnt>
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-dev@jakarta.apache.org>
References: <006901c0ea9f$235226e0$60c4223f@cognetnt>
Subject: Re: [DISC] Aspect implementation
Date: Sat, 2 Jun 2001 00:19:03 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

For those who are unfamiliar with the concept of aspects, you can try the
following links which discuss AspectJ, an implementation of aspects for
Java.

http://aspectj.org/servlets/AJSite

http://aspectj.org/doc/gettingStarted/index.html

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.

Conor

----- Original Message -----
From: "Conor MacNeill" <conor@cortexebusiness.com.au>
To: <ant-dev@jakarta.apache.org>
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
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"
>              dir="jakarta-ant/proposal/mutant">
>     </fileset>
>
> The "ant:" triggers the aspect The aspect is defined in the antlib.xml
with
> 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
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
> point.
> 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
> configured.
> 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.
>
> Thoughts?
>
> Conor
>
>
>