------------Original Message------------
From: Russell Miles <russellmiles@xxxxxxx>
To: aspectj-dev@xxxxxxxxxxx
Cc: russellmiles@xxxxxxx
Date: Tue, Feb-1-2005 7:11 AM
Subject: [aspectj-dev] Extensions to reflection in AspectJ in support
of aUnit
Hi everyone,
I've got a couple of 'feature requests' (none of which will be any
surprise to Adrian and the guys I'm sure :) to run by you all. These
requests are all in support of the aUnit development that I'm doing
at the
moment.
In order to be able to effectively construct advice focussed unit
tests
I need to have a reflection architecture that is similar to the
traditional Java structures. For example, just as Java has it's Class
object
associated with every class I could do with having something very
similar for each aspect. This would mean that every aspect would have
an
associated Aspect class to support reflection. Each Aspect class would
allow access to advice blocks for test based invocation based on a
'standard' AspectJ annotation.
The Aspect class would specifically need the following features for my
aUnit work:
1) A getAdvice() method that returns an array of Advice objects
representing all of the advice blocks within an aspect.
2) A getAdvice(String annotatedName) method that returns a single
Advice object based on an AspectJ 'standard' annotation for naming
advice in
support of aUnit testing.
The Advice class would in turn need the following features:
With these features I could do something like the following in aUnit:
Aspect aspect = <aspect class name>.getAspect();
Object aspectInstance = aspect.getInstance(); // could just do this
with aspectOf() call
Advice advice = aspect.getAdvice("<aUnit Annotation advice name");
JoinPoint[] testJoinPoints = new JoinPoint[2];
testJoinPoints[0] = new JoinPoint(<params such as this reference,
target reference etc>);
testJoinPoints[1] = new JoinPoint(<params such as this reference,
target reference etc>);
aspect.invoke(aspectInstance, advice, testJoinPoints);
As you can see, I'd need an extended implementation of the JoinPoint
class for my purposes as well .. whether this is an extension to the
existing JoinPoint class or something completely different, I'm not
sure.
The JoinPoint class instantiation is an interesting problem as it is
more than likely that you would want to throw many disparate types of
join point, with varying contexts, at the same advice block during the
course of running a test. I'm also looking to make this more
manageable by
providing a join point factory which will read a supplied
configuration
(XML based) and create a selection of join points for the particular
test. For example:
JoinPoint[] joinPoints =
org.aspectj.aunit.JoinPointFactory.buildJoinPoints(URL configuration,
String testName);
I'm more than happy to put these changes into the codebase myself if
anyone can point me at a good place to get started and if everyone is
ok
with my approach so far?
One last point is that it might be nice to use the policy pattern to
implement a compiler warning (using an aspect of course :) if advice
is
being invoked outside of aUnit ... indicating that the invocations and
exposure of advice are not really in the spirit of AOP? Could just do
this in aUnit only...
If anyone can point out that there are existing, or even better, ways
of achieving this sort of functionality then please let me know,
otherwise it'd be great, if acceptable, to get these features into
AspectJ.
Oh, and if I should add this request more formally somewhere else then
point me at that too.
Cheers,
Russ
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev