[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Q about "adviceexecution" and "declare error"
|
Hmmm, so you don't believe the entire body of works on open modules then?
http://citeseer.ist.psu.edu/aldrich04open.html
http://doi.acm.org/10.1145/1119655.1119664
Note that those works propose both, aspects which a module is
"protected" from as well as aspects which deliberately break this
encapsulation, e.g. for the purpose of debugging.
I know whole research communities which believe that not being able to
guarantee any sort of encapsulation by far the largest problem of
AspectJ.
Eric
On 2/22/07, Matthew Webster <matthew_webster@xxxxxxxxxx> wrote:
Dean,
I'm working on idioms for defining PCDs that a class developer can use to exclude join points from possible advices. For example, say I want a 'critical section' to never be advised.
Requests to allow the author of a class to say "don't weave my code" crop up quite regularly. They come in a number of forms e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=47919. Unfortunately such a feature is incompatible with AOP and I distinctly remember Gregor Kiczales talking on the subject in his keynote at AOSD 2003. If a single join point becomes off limits to an aspect there is a risk that it won't work and hence will be invalid. The false assumption is that the consequences of weaving the code will always be worse than not weaving it. For example one of the many compelling use cases for AOP is in-field problem diagnosis and the feature you are suggesting would turn "protected" code, that would start off as one or two methods but would quickly end up as whole applications when the capability is abused, into a black hole.
Knowing whether your code is being advised is a different matter. For this reason we have worked on the Cross-cutting Comparison view in AJDT and extensive messages on other diagnostics for LTW. You can't stop the modification of an open byte-code format so in my view its better to let someone do it with AspectJ, which allows them to express themselves at the right level and hence is less prone to error, than something that operates at a much lower level.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM United Kingdom Limited
Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
"Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx
21/02/2007 17:30
Please respond to
aspectj-users@xxxxxxxxxxx
To <aspectj-users@xxxxxxxxxxx>
cc
Subject RE: [aspectj-users] Q about "adviceexecution" and "declare error"
Hi Dean,
The declare error doesn't apply because the advice is dispatched from those methods but it isn't executed within them. You are asking for a new pointcut, say advised, that is to adviceexecution as call is to execution (modulo the difference between implicit and explicit dispatch).
________________________________
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Dean Wampler
Sent: Tuesday, February 20, 2007 12:07 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Q about "adviceexecution" and "declare error"
Ron Bodkin wrote:
Indeed, you would want a withinadvice pointcut, but failing that you might just refactor to expose the relevant code as a method. Of course, to have something like withinadvice be useful, I'd want AspectJ to have better matching on advice signatures too (so you could say adviceexecution(before(int, String))).
Agreed.
What I ended up doing was writing a PCD that looks something like this:
cflow(execution(* MyClass.myRestrictedMethod(..)) && adviceexecution() && !within(ProhibitAdvice+)
(ProhibitAdvice is the aspect...)
Then I used before advice to throw an exception. Again, my particular goal is to prevent any advice from being invoked within the execution context of "myRestrictedMethod()".
Here's what I find perplexing. The following does nothing:
declare error: withincode(* MyClass.myRestrictedMethod(..)) && adviceexecution(): "message";
Looking at the AJDT adornments, it's clear that advice is being applied within the method, from another aspect designed to trigger the error (the adornment doesn't have a '?' on it ;). What am I missing? I thought of precedence, but experiments there didn't do anything.
Thanks,
dean
________________________________
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Dean Wampler
Sent: Tuesday, February 20, 2007 8:35 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Q about "adviceexecution" and "declare error"
Thanks, Ramnivas,
I was under the mistaken impression that adviceexecution works something like a "withincode" or "cflow", which of course it doesn't.
dean
Ramnivas Laddad wrote:
Dean,
Since adviceexecution() will match an advice join point and criticalSectionPCD() will match a non-advice join point (in your case, I presume you are selecting execution() or call() join point), combining the corresponding pointcuts using && will match nothing.
-Ramnivas
On 2/20/07, Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx> wrote:
I'm working on idioms for defining PCDs that a class developer can use to exclude join points from possible advices. For example, say I want a 'critical section' to never be advised.
What I've tried is something like the following:
declare error: criticalSectionPCD() && adviceexecution(): "Can't advise the critical section."
This compiles fine, but it has no effect. (I defined another aspect that breaks the rule.)
Suggestions?
dean
________________________________
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
--
Dean Wampler, Ph.D.
dean at aspectprogramming.com
objectmentor.com
aspectprogramming.com
contract4j.org
I want my tombstone to say:
Unknown Application Error in Dean Wampler.exe.
Application Terminated.
Okay
Cancel
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
________________________________
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
--
Eric Bodden
Sable Research Group
McGill University, Montréal, Canada
