Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] RE: [aspectj-dev] Named Advice revisited.

Title: Message
While in AspectJ advice are different from methods, there's no reason for making that distinction in general. You can have a language where the crosscutting behavior is implemented in regular methods of special classes -- classes that know about join points.
 
You gain in unit testing those pieces of behavior, pretty much as you describe below: mocking the join point. 
There's advantages in mocking the join point information: you can test a piece of crosscutting behavior in isolation as if it were being executed in a certain join point. (That's the value of mock objects.)
One of my students is doing it with a simple prototype language called Jaml; the testing framework, JamlUnit, is described here:
(will be presented in the upcoming WTAOP workshop @ AOSD'05)
 
-Crista
 
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Russell Miles
Sent: Tuesday, February 22, 2005 9:27 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] RE: [aspectj-dev] Named Advice revisited.

(I’m CC’ing users on this message because that’s where the unit testing discussion took place)

 

The idea of named advice has popped up a few times.  Usually it’s because someone wants *labels* for advice, e.g. for the IDE’s outline view, or for the stack trace entry in a debugger thread tree.  But labels are not the same thing as names and could be added with an annotation on the advice.  Names are used to invoke things explicitly.  The beauty and utility of advice comes from it being invoked implicitly as the result of join point matching.

 

Recently another use case for naming advice popped up on the list, as a means of explicitly invoking advice so that it can be unit tested.  In my opinion advice are not methods, and can not be unit tested in the same way that methods can.  When you unit test methods you need to mock up the object parameters to the method, and then invoke it explicitly.  It seems to me that when you’re unit testing advice you need to mock up the join point context in a way that invokes the advice implicitly (i.e. create some kind of join point context object that causes the appropriate pointcut to match by specifying signatures and type patterns, setting the values of any args(), this() and target() referenced, and possibly setting up anything needed from a cflow stack).  Then you pass your join point context and an aspect type reference to a unit testing framework which is responsible for invoking the corresponding advice.  If you don’t care about all that context stuff, and really just want to unit test the body of the advice, then simply create a method for the body, make the only line in the advice a call to the method, and unit test the method.

 

Jean-Sebastien, you bring up a third use case: adding names so that advice can be more easily matched by a pointcut.  In AspectJ 5 I already think that it’s convenient enough.  You’ve always been able to match advice using within(), and now you’ll be able to match it using annotations on the advice.  But I’ve never seen a compelling use case for this, other than someone suggesting that they might want to log all advice.  Again, they can do that without naming.

 

Other people’s opinion on this may differ, but I see no need to make advice more like methods by giving them names.  When you want implicit invocation based on join point matching, you use advice.  When you want explicit invocation by name, you use methods.  Naming advice will muddy those waters.  As you point out, it will also add OOP inheritance facilities (e.g. overriding) to advice.  AspectJ’s stance is that AOP inheritance is about abstracting and concretizing pointcuts, and not about extending and overriding behavior.  Notably other approaches such as JBoss AOP and Spring AOP provide the latter for advice by using method names for them, so we’ll learn more about those consequences of that approach before too long.

 

So in short, I still haven’t heard a compelling use for naming advice.  But a discussion of these and other potential uses of naming advice could be a useful research contribution.

 

Mik

 


From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Jean-Sebastien Boulanger
Sent: Friday, February 18, 2005 11:44 AM
To: aspectj-dev@xxxxxxxxxxx
Subject: [aspectj-dev] Named Advice revisited.

 

Hi all,

 

As an experimental project I'm currently looking into extending aspectJ syntax using the aspectbench compiler (www.aspectbench.org) to support named advice. The extension will support pointcut that can match advices by name.

 

I'm also trying to figure out what should be the overriding rules for the named advice (if you can override or not a named advice in a sub-aspect) and I red in the archive of the mailing list that the idea that a named advice could override/extend advices with the same name is 'truly frightening'. I'm not sure I understand conceptually why it is so frightening, maybe my mind is still thinking OO too much...anyway it would be very appreciated if someone could explain to me in more details???

 

Thanx a lot!

 

Jean-Sebastien


Back to the top