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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] http://w3.hursley.ibm.com/~websterm/ "Ron Bodkin" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 21/02/2007 17:30 Please respond to [email protected] To <[email protected]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wampler Sent: Tuesday, February 20, 2007 12:07 PM To: [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wampler Sent: Tuesday, February 20, 2007 8:35 AM To: [email protected] 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 <[EMAIL PROTECTED]> 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 [email protected] 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 [email protected] 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 [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
-- Eric Bodden Sable Research Group McGill University, Montréal, Canada _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
