1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
testing privileged aspects
These notes apply to subdirectories util, pack, and driver.
---- privileged aspects
- A privileged aspect ignores Java's accessibility rules and can access
any members anywhere in the world regardless of access restrictions.
- The privilege extends to anything in the lexical scope of the
privileged aspect, including inner classes and aspects
- the privilege does not extend to members introduced
onto the privileged aspect
- the privilege does not extend to subaspects
- a privileged aspect can be public
- a privileged aspect can be an inner aspect
even a static inner aspect of a class
- In some cases, providing this private access changes the access
permissions in the generated (byte)code, visible to other
classes compiled or running with the target class.
However, in the scope of the AspectJ compilation process,
only the privileged aspect should enjoy enhanced permissions
- type names from external packages must be fully qualified in the
privileged aspect. the visibility of import statements in the
file of the privileged aspect is unchanged.
- as a result, if {static} inner aspects are permitted, they will
be unable to bind some names that their enclosing class/aspect
can bind unless they fully qualify the names.
---- testing privileged aspects
- binding: testing binding involves ensuring the class or aspect
can (or cannot) bind a name to a type or member at compile time
and can actually use that reference at runtime without an
IllegalAccessException
testable statements:
1 any aspect may be privileged, including abstract and inner aspects,
including static inner aspects of classes
2 privileged aspects can bind any members of targets
- targets: classes, inner classes; aspects, inner aspects;
in the same package, a different package, and the default package
- sources in the privileged aspect:
- constructors, static and instance methods and initializers
- bodies for introduced methods and member initializers
- pointcut declarations
- pointcut pcd if() bodies
- advice bodies
- the same for inner classes and aspects
3 when privileged aspects get this access, access does not change for
other classes in the same set of files compiled
4 2 is not true of non-privileged subaspects of a privileged aspect
5 AspectJ will open up the target class to the minimal extent possible,
subject to these rules:
- the access permissions for the privileged access will not change
- the class hierarchy of the privileged aspect or the target class
will not be modified to gain protected access
- if protected access is available, AspectJ will not convert
to default/package access or to public access
- if default/package access is available, AspectJ will not convert
to public access
6 code in privileged aspects has no enhanced runtime permissions for
reflective access to (target classes or) non-target classes
test plan:
1 compile-time binding test:
- public and default access classes in one package
each with a corresponding inner class (public/default)
each class has static and instance members of all access types
-> pack.PublicTarget, pack.DefaultTarget
- privileged aspect in another package
accesses all target methods/members from static methods
-> driver.PrivilegedAspect
2 test 1 with the aspect as an inner aspect
- unprivileged inner aspect of a privileged aspect
- privileged inner aspect of an unprivileged aspect
- static privileged inner aspect of a class
3 test 1 with errors expected for protected/private/default access
for a non-privileged subaspect
-> driver.UnPrivilegedAspect
----- Priority 3 tests
4 test 1 with errors expected for private/default access
for a non-privileged subaspect inner class of a target subclass
5 test 1 with errors expected for private access
for a non-privileged aspect in the same package
---- current status
Aggregate versions of tests 1 and 3 done; 2 is close. See -> above.
Error tests are brittle since it is undefined how many errors the
compiler will find in a file before giving up. The error test
cases should be broken out into separate test cases/files.
|
