| | É. Tanter, “Execution levels for aspect-oriented programming,” Proceedings of the 9th International Conference on Aspect-Oriented Software Development, Rennes and Saint-Malo, France: ACM, 2010, pp. 37-48. DOI = http://portal.acm.org/citation.cfm?doid=1739230.1739236
Robin's Review
Problem |
|
>
> | This paper focuses on a common pitfall in AOP languages built on pointcuts and advice: aspects whose pointcuts are matched in their own advice, leading to infinite loops or recursion in advice weavers or the code they produce. While identified as a fundamental issue in AOP, the recent addition of pointcuts that can invoke code themselves exacerbates the problem. The paper describes and critiques several common solutions to the problem, including using control-flow pointcuts to exclude advice execution and adding extra primitives to the language to hide execution join points from weaving. |
| | Contributions |
|
>
> | This paper claims to provide a solution to infinite regression in the form of "execution levels", wherein each instant in execution (base or advice) is associated with an unbounded number of discrete ordered levels. Advice is declared to only apply to the level immediately below the level it is defined at, and by default advice is declared at the level immediately above the code that declares it, with the net effect that advice normally does not advise other advice code. Shifting operators are provided to allow code to explicitly override this behaviour, in order to selectively restore the conflation of base and advice code for situations where this is the desired behaviour.
The author provides an abstract description of this extension, and concrete semantics for an application of it to AspectScheme, an AOP language based on Scheme. |
| | Weaknesses |
|
>
> |
- The examples of infinite regression described early on in the paper all seem to have better possible solutions when considered individually:
- 2.1 (The Activity aspect that applies unintentionally to the Point#toString method): the key issue here is that the toString() method is incorrectly considered relevant to this aspect: simply excluding the toString() method from the relevant pointcut would be a simpler and more reliable solution. This reflects the fact that code has a lot of constraints and implicit rules that advice needs to be aware of in order to function correctly in general.
- 2.2 (Pointcut loops): I'm personally very uncomfortable with pointcut expressions including normal code, and would much rather not include pointcuts such as AspectJ's "if". There is also evidence that this is confusing for developers: http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg06195.html. Dealing with join points inside pointcut expressions feels like a superficial improvement on a much deeper problem.
- 2.3 (Control-flow exclusion not working with "around" advice): I would call this a bug in the "adviceexecution" pointcut, as the "proceed()" syntax is not a regular method call. It would be much more consistent to exclude code triggered by resuming from advice code from this pointcut.
- 2.4 (Visibility of aspects): interaction of aspects does indeed have to be controlled carefully, but aspect dependency management is part of languages like AspectJ already. The complexity of this convinces me that a single ordered dimension of visibility isn't adequate for a mature code base.
- 2.5 (Concurrency): again, this issue is avoided if the pointcut is customized to exclude toString() explicitly.
- The assumption that avoiding infinite regression is fundamentally safer is demonstrably false. As illustrated in the paper, unintentional interaction of aspects can lead to immediate failure in the form of infinite recursion, but non-interaction can lead to missing behaviour, which is much harder to identify. A security-related aspect, for example, could fail to track or access-control references to vulnerable functions simply because they have been refactored into aspects!
- The fact that the proposed solution is presented in Scheme notation and semantics makes it difficult to relate the solution back to the examples of the problem from Section 2. This runs deeper than mere reader understanding, in fact: because the solution is given in a language where pointcuts and advice are treated as first-class values, and declaring aspects is performed inline with normal execution rather than statically, I'm not convinced it is actually reasonable to apply execution levels properly to AOP languages like AspectJ.
|
| | Questions |
|
>
> |
- Is infinite regression of advice fundamentally harder to debug, understand and correct than classic infinite recursion or looping in non-AOP code?
- Are there other potential pointcut varieties needed to avoid all cases of infinite regression?
- What was the intended benefit of adding the "if" pointcut to AspectJ, when it should be equivalent to wrapping the advice body in the same if condition?
|
| | Belief |
|
>
> | I believe this paper does a good job of identifying a common difficulty with AOP languages, but misses the mark with its assessment of where the true issue lies. The idea of execution levels is reasonable and well-formed in of itself, but is not a convincing alternative to other solutions not considered in their evaluation, and in my opinion its downsides are worse than the current state of the art. |
| | Nick's Review
Problem
The paper describes a problem with existing AOP implementations. Advice contains base level code -- i.e. code which may trigger pointcuts. Pointcuts were originally intended to be "meta" constructs, but, in practice, their definitions can also contain base level code. The consequence is the possibility of infinite regression through pointcut loops or advice loops. Existing workarounds rely on the cflow pointcut, which can disable advice based on the calling context. The creation of a "pointcut execution pointcut" would allow this workaround to apply to pointcut loops as well. However, this workaround cannot deal with the case of "around" advice. It also fails to handle variable aspect visibility within the same advice, and advice which delegates execution to another thread.
Contributions
- One contribution seems to be laying out the different dimensions of the problem, and showing that control-flow-based approaches cannot address "around" advice, variable aspect visibility, and concurrency issues.
- The other contribution is a plausible path forward. The notion of an execution level is easy to grasp and seems to mesh with basic intuitions about how pointcut evaluation and advice execution should work.
Weaknesses
- It's a bit unsatisfying that, in order to deal with the case where advice runs in a separate thread, a new lambda abstraction has to be introduced. This seems to contradict the goal of making the default behaviour safe for the average programmer.
- The paper mentions the possibility of deploying aspects at higher levels, so that they can monitor aspects below them. A limitation of this seems to be that the user must deploy the aspect at all the levels they wish to monitor. This would likely be very tricky to manage. Who deploys the aspects? Do they know which levels a given aspect should be deployed at? My guess is that the more popular way to expose aspect execution would be through level shifting.
- The paper briefly mentions the "disable" primitive of AspectML, which can turn off pointcuts during evaluation of an expression. With execution levels, if we assume that most aspects will run at level 1, and exposing the execution of these aspects will be done through level shifting, the code and behaviour starts to look very similar to code using the disable primitive. The paper does not devote enough attention to how the two approaches differ, and what advantages come with execution levels.
Questions
- The proposed default behavior is for pointcuts and advice to be evaluated at level 1 -- i.e. not "visible" to aspects deployed by code at level 0. Is this a reasonable default -- is the average AOP programmer likely to find this natural?
- The up/down operators allow the implementor of the advice to decide whether other aspects get to "see" a given part of the advice. Is it correct to leave this decision entirely up to the one writing the advice?
- Is the proxy-based AOP approach of Spring vulnerable to the issues described in this paper?
Belief
I think this is a useful, but flawed paper. It lays out the problem clearly, and makes a convincing case that current workarounds are not sufficient. On the surface, the construct of execution level seems a pretty natural way of resolving the tension. For practical purposes, however, it is not clear how much this improves on the "disable" primitive proposed for AspectML. |
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.