Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Extensions to reflection in AspectJ in support of aUnit 
Hi Wes,

To answer some of your questions:


Is aUnit on sourceforge or something?  It would be interesting
to concretely see this.
I'm looking to get a sourceforge project set up over the next couple of days. The codebase is pretty small at the moment, still sounding out some ideas, but that will most likely all change over the next week as I now have some real time I can spend on the task. 


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.
Yep, that's exactly the route I was taking and I think, accompanied with your advice from the previous paragraph in your response, that it's about time I got some of this written into the aUnit source. Then, when the sourceforge project is happy, we'll have something more concrete to play with :)
I'm interested in the aside on language support .. .but I reckon that once I have something more concrete working here then that might provide some more light as to whether there's a just cause for that. 

Thanks for your input!

Cheers,

Russ

On 2 Feb 2005, at 02:19, Wes Isberg wrote:


Hi Russell -



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




_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev

Back to the top