Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010602042207.0093c710@mail.alphalink.com.au>
Date: Sat, 02 Jun 2001 04:22:07 +1000
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: [DISC] Aspect implementation
Cc: <ant-dev@jakarta.apache.org>
In-Reply-To: <006901c0ea9f$235226e0$60c4223f@cognetnt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:30 PM 6/1/01 +1000, Conor MacNeill wrote:
>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).

I think I prefer 2. If you recall a while back there was discussion of
"context" task (like recorder but generalized to all "aspects"). So you
could define a context that said log verbosly and do Y. This was given as
an alternative to aspects. After further discussion it was discovered that
"contexts" (which I call facilitys) are complimentry to aspects. 

For example the example used was logging. In this case you configure the
facility to log to file foobar.txt with formatter Y and layout Z. The
logging facility was an AspectHandler. It could also take per-task
parameters (ie only log task at error level) which are provided by the
namespaced attributes/elements on task.

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

I can't see any problem here as I assume that we will just be handing back
the task proxy/model/configuration to executor and the executor will handle
all aspects.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*