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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 > > >
