Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base-code can lead to join points incorrectly falling in or out of the scope of pointcuts. In this paper, we present an automated approach that limits fragility problems by providing mechanical assistance in pointcut maintenance. The approach is based on harnessing arbitrarily deep structural commonalities between program elements corresponding to join points selected by a pointcut. The extracted patterns are then applied to later versions to offer suggestions of new join points that may require inclusion. To illustrate that the motivation behind our proposal is well founded, we first empirically establish that join points captured by a single pointcut typically portray a significant amount of unique structural commonality by analyzing patterns extracted from twenty-three AspectJ programs. Then, we demonstrate the usefulness of our technique by rejuvenating pointcuts in multiple versions of three of these programs. The results show that our parameterized heuristic algorithm was able to accurately and automatically infer the majority of new join points in subsequent software versions that were not captured by the original pointcuts.
Poster on Automated Refactoring of Legacy Java Software to Default Methods
Pointcut Rejuvenation: Recovering Pointcut Expressions in Evolving Aspect-Oriented Software
1. Pointcut Rejuvenation: Recovering Pointcut
Expressions in Evolving Aspect-Oriented
Software
Raffi Khatchadourian, Ohio State University
Joint work with Phil Greenwood and Awais Rashid, Lancaster
University, UK and Guoqing Xu, Ohio State University
Work in progress at University of Tokyo with Hidehiko
Masuhara
6. Motivation
• Software changes over
time:
• Requirements evolve
• New platforms emerge
(e.g., mobile devices)
• Frameworks
change(e.g., XML vs.
annotation-based)
8. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.
9. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.
10. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.
11. Motivation
Changing and/or maintaining large, complex software
systems can be non-trivial:
Tedious: May require changing many lines of
code.
Error-prone: Changes may be implemented
incorrectly.
May miss opportunities to produce
Omission-prone:
better code.
14. Approach
• Approaches made to
provide mechanical
assistance in evolution
tasks.
• Typically in the form of
plug-ins to IDEs.
15. Approach
• Approaches made to
provide mechanical
assistance in evolution
tasks.
• Typically in the form of
plug-ins to IDEs.
• Ease the burden of
software maintenance
and evolution.
16. Approach
Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.
• Typically in the form of
plug-ins to IDEs.
• Ease the burden of
software maintenance
and evolution.
17. Approach
Restrict
workspace to only
• Approaches made to displays elements
provide mechanical relevant to the
assistance in evolution task
tasks.
• Typically in the form of
plug-ins to IDEs.
Restructure
•code the burden of
Ease while preserving
semantics (i.e.,
software maintenance
and evolution.
refactoring)
19. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
20. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
21. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.
22. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present: Pointcut Rejuvenation
• Existing work on altering broken pointcut
expressions using an automated technique.
23. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.
• Current work on automatically detecting broken
pointcuts as the developer is typing.
24. Goal and Outline
• Develop techniques to mechanically alleviate the
burden caused by fragile pointcuts in Aspect-
Oriented software.
• Will present:
• Existing work on altering broken pointcut
expressions using an automated technique.
• Current work on automatically detecting broken
pointcuts as the developer is typing.
Pointcut
Change Prediction
26. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
27. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
28. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.
29. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.
• Tangled with unrelated modules.
30. Crosscutting Concerns in Software
• Crosscutting concerns (CCCs) affect many
heterogenous modules of a typical software system.
• Code is usually:
• Scattered throughout many modules.
• Tangled with unrelated modules. include logging,
Classic CCCs
synchronization,
authentication.
35. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
36. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
Base code
37. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
38. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
39. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.
40. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs:
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.
• Executed whenever control reaches any join point
selected by the pointcut.
41. Aspect-Oriented Programming
• Aspect-Oriented Programming (AOP) enables
localized implementations of CCCs: Focus of
today’s talk
• CCC implementations encapsulated in advice.
• Pointcuts:
• Predicate-like expressions over well-defined (join)
points in a program’s execution.
• Denote where a CCC applies.
• Advice is:
• Bound to a pointcut.
• Executed whenever control reaches any join point
selected by the pointcut.
42. Example Base Code
package p;
class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}
43. Example Base Code
package p;
class A {
int f;
void m1() {
int a = f + 1;
}
void m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}
44. Example Base Code
package p;
class A {
• Two methods whose int f;
name begins with the
character m. void m1
m1() {
int a = f + 1;
}
void m2
m2() {
int b = f + 2;
}
void n() {
f = 3;
}
}
45. Example Base Code
package p;
class A {
• Two methods whose int f;
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
}
void n
n() {
f = 3;
}
}
46. Example Base Code
package p;
class A {
• Two methods whose int f;
f
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
• Method bodies of m1 and }
m2 read from a field f. void n() {
f = 3;
}
}
47. Example Base Code
package p;
class A {
• Two methods whose int f;
f
name begins with the
character m. void m1() {
int a = f + 1;
• One method whose name }
does not begin with the
character m.
void m2() {
int b = f + 2;
• Method bodies of m1 and }
m2 read from a field f. void n() {
f = 3;
• Method body of n writes }
to field f.
}
51. Pointcut Example
pointcut mayBeFragile() :
execution(* m*(..));
• Selects m1() and m2()
but not n().
• Assume that correct join
points are selected.
CCC
applies to m1 and m2
but not p.
53. Pointcut Properties
• A pointcut is robust if it is able to continue to capture
the intended join points in future base code versions
without being altered.
54. Pointcut Properties
• A pointcut is robust if it is able to continue to capture
the intended join points in future base code versions
without being altered.
• Otherwise, it is fragile.
55.
56. void p() {
int d = f + 4; A new method
} is added to the base
code
57. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
W
ha
ta
po bo
int ut
cu th
t? e
58. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
59. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
60. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!
61. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!
• p() silently fall out of pointcut’s scope.
62. void p() {
int d = f + 4;
}
pointcut mayBeFragile() :
execution(* m*(..));
• Same pointcut selects m1() and m2() but not
n() and p().
• Assume CCC applies to p().
• mayBeFragile() is fragile!
• p() silently fall out of pointcut’s scope.
• May be difficult to identify in large base codes.
64. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
m1
gets declares
f gets m2 declares A
sets declares
n
65. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
• Extract commonalities between currently selected
join points.
m1
gets declares
f gets m2 declares A
sets declares
n
66. Phase I: Leverage Structural Commonality
• Build a Concern Graph [Robillard, Murphy ’02].
• Extract commonalities between currently selected
join points.
• Find common sinks and sources in the graph.
m1
gets (A,declares,?)
declares
f (?,gets, f)
gets m2 declares A
sets declares
n
67. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
m1
gets declares
f gets m2 declares A
sets declares
n
68. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
{m1,m2}
m1
gets declares
f gets m2 declares A
sets declares
n
69. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100%
confidence!
{m1,m2}
m1
gets declares
f gets m2 declares A
sets declares
n
70. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100%
confidence!
{m1,m2} {m1,m2,n}
m1
gets declares
f gets m2 declares A
sets declares
n
71. Evaluating Patterns
[Dagenais, Breu, Warr, Robillard ’07]
(?,gets, f) (A,declares,?)
100% 66%
confidence! confidence
{m1,m2} {m1,m2,n}
m1
gets declares
f gets m2 declares A
sets declares
n
72. Storing patterns for Phase II
(?,gets, f) (A,declares,?)
100% 66%
confidence! confidence
XML
75. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
76. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
77. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
78. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
79. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
80. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:
81. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:
• Considers the ratio of wild-cards (?) to concrete elements in
the pattern as patterns can be arbitrarily deep.
82. It’s a little more complicated ...
• Pattern evaluation is done on several other different levels.
• Previously illustrated the α evaluation:
• Considers the strength of the structural relationships between
elements produced by the pattern and those selected by the
pointcut.
• Another dimension is the β evaluation:
• Considers the completeness of the structural relationship
expressed by the pattern compared to relationships expressed
by the pointcut.
• Lastly, there is an abstractness evaluation:
• Considers the ratio of wild-cards (?) to concrete elements in
the pattern as patterns can be arbitrarily deep.
• All three dimensions are combined to produce a patterns
confidence value.
83. SACTIONS OF SOFTWARE ENGINEERING, VOL. X, NO. Y, Z 20AB
0 if | Match (ˆ , Paths ( C G + ))| = 0
π
err (ˆ , PCE) =
π |PCE ∩ Match (ˆ , Paths ( C G + ))|
π
1 − otherwise
| Match (ˆ , Paths ( C G ))|
π +
1 if |PCE| = 0
err (ˆ , PCE) =
π |PCE ∩ Match (ˆ , Paths ( C G + ))|
π
1 − otherwise
|PCE|
1 if |ˆ | = 0
π
abs (ˆ ) =
π |ˆ | − |W(ˆ )|
π π
1 − otherwise
|ˆ |
π
conf (ˆ , PCE) =
π 1 − [err (ˆ , PCE)(1 − abs (ˆ )) + err (ˆ , PCE) abs (ˆ )]
π π π π
Pattern attribute equations.
allSpeed). Thus, the err rate for this pattern projection of wild card elements contained
e PCE found on line 3 of Figure 2, which selects π . Likewise, |W(ˆ )| represents the number o
ˆ π
ution of methods DieselEngine.increase(Fuel) and elements contained within pattern π . Then, t
ˆ
93. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code
94. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code
m1
gets declares
f gets m2 declares A
sets declares
gets n declares
p
95. Phase II: Expression Recovery
void p() {
int d = f + 4; A new method
} is added to the base
code
m1
(?,gets, f)
gets (A,declares,?)
declares
f gets m2 declares A
sets declares
gets n declares
XML
p
119. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
120. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
121. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.
122. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.
• On average, 3.97 suggestions appeared before true
positives.
123. Evaluation: Phase 2
• Applied to 3 multi-versioned AspectJ projects.
• Rejuvenated pointcuts (49 in total) over major
releases (20 in total).
• Maximum pattern length set to 2 edges.
• Able to identify 93% of new shadows introduced in
later versions that were not selected by previous
pointcut representations.
• On average, 3.97 suggestions appeared before true
positives.
• On average, 10.95 secs. required to rejuvenate a
pointcut.
133. More Future Work
• Additional language features:
• Inter-type declarations.
134. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
135. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:
136. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:
• Source code version repository history information.
137. More Future Work
• Additional language features:
• Inter-type declarations.
• Advice code analysis.
• Additional forms of commonality:
• Source code version repository history information.
• For example, several methods may have been
committed together in one SVN version.
138. Downloads
• Tool research prototype publicly available at http://
code.google.com/p/rejuvenate-pc.
• Research related material publicly available at http://
sites.google.com/site/pointcutrejuvenation.
Editor's Notes
\n
\n
\n
\n
\n
Changing a method to accommodate a new parameter requires changing the method declaration for each method in the type hierarchy, examining other methods in the hierarchy to assure they are not being overridden, and altering each method invocation site scattered throughout the source code.\n\nHashMap iterator is fail-safe while Hashtable enumerator isn't. If you change the map while iterating, you'll know.\n\n
Changing a method to accommodate a new parameter requires changing the method declaration for each method in the type hierarchy, examining other methods in the hierarchy to assure they are not being overridden, and altering each method invocation site scattered throughout the source code.\n\nHashMap iterator is fail-safe while Hashtable enumerator isn't. If you change the map while iterating, you'll know.\n\n
Changing a method to accommodate a new parameter requires changing the method declaration for each method in the type hierarchy, examining other methods in the hierarchy to assure they are not being overridden, and altering each method invocation site scattered throughout the source code.\n\nHashMap iterator is fail-safe while Hashtable enumerator isn't. If you change the map while iterating, you'll know.\n\n
Changing a method to accommodate a new parameter requires changing the method declaration for each method in the type hierarchy, examining other methods in the hierarchy to assure they are not being overridden, and altering each method invocation site scattered throughout the source code.\n\nHashMap iterator is fail-safe while Hashtable enumerator isn't. If you change the map while iterating, you'll know.\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
Advice is not explicitly invoked.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
Definition of fragile is the the PCE continues to select the desired join points as base-code evolves without a change in its textual representation.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n
There’s also the reverse situation where selected join points may no longer belong in the scope of the pointcut. We won’t discuss that today for brevity.\n