Re: [aspectj-dev] Extensions to reflection in AspectJ in support of aUni

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

Hi Russell -

Is aUnit on sourceforge or something?  It would be interesting
to concretely see this.  

We've resisted having advice be named and directly executed for
a number of reasons.  One is whether the compiler needs to be
consistent in how it implements advice, particularly across 
versions.  I'm also not sure it gets you what you need without
naming, since the association between tests and advice might
break if the advice were reordered.

So since this is implementation-dependent, perhaps we could start 
by making it the responsibility of aUnit to surface the advice.
I suspect you could implement it initially by writing a small class 
loader to strip off the synthetic attributes of the advice[1], and
decide how you'd like to identify them to the client (e.g., you 
might pull the source location attribute).  In any case, you'd
have to confront the question of identifying advice in a way that
it's the same when moved around, etc.  When doing that you might
come up with a proposal that we could implement.

Of course, I'm sure you're considering Java 5 annotations.  Users
could supply their own names for advice, which aUnit would then find
as usual (modulo stripping the synthetic attribute and doing fixups)
and identify using the annotations.  That seems doable.

Not to duck the hypothetical, but we've been testing advice for some 
time by running a relevant set of advised join points (what's relevant 
is another question :).  For complex advice I find that I delegate as 
much as possible to straight Java, which is testable as usual.  So 
there's a "best practices" workaround now.  It would be interesting 
to consider whether that would be a common enough idiom to justify 
language support, along the lines of

  before(String s) : pc(s) : someMethod(s);

(not to stir up controversy in an aside...)

Wes

[1] This is predicated on the synthetic attribute being the only
barrier to reflection, which is complete conjecture on my part.

> ------------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
>