[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Re: when final is not
|
AOP should always be used wisely by people who has the privilege or
authorized by privileged people on the code it intercepted with. Thus,
aspect should not restrict on final or private fields but a privileged
advice should somehow gain security manager's approval - something to do
with signed jar. Only authorized by the original signer, a privileged
advice can access and intercept with final and private fields or any access
detour from java access rules. Non privileged advice should not be allowed
to access anything that is violate java access rules.
In case of source code, classes or non-signed jars, aspect should be
treated as privileged who has the right to do all the things that aspectj
allows.
In such a controlled way, we may gain enough power by using aspect on
tracing/debugging/monitoring existing systems but prevent misuse the super
power.
Cheers,
Bo
----------------------------------------------------------
Dr. Bo Yi
WAS L3 Support
IBM Toronto Lab
A2-713/Q2Z/8200/MKM
8200 Warden Ave. Markham ONT. L6G 1C7
Phone: 905-413-4819
Tie Line: 969-4819
E-Mail: boyi@xxxxxxxxxx
|---------+------------------------------->
| | Wes Isberg |
| | <wes@xxxxxxxxxxxxxx>|
| | Sent by: |
| | aspectj-users-admin@|
| | eclipse.org |
| | |
| | |
| | 01/14/2004 07:31 AM |
| | Please respond to |
| | aspectj-users |
|---------+------------------------------->
>-----------------------------------------------------------------------------------------------------------------|
| |
| To: aspectj-users@xxxxxxxxxxx |
| cc: |
| Subject: Re: [aspectj-users] Re: when final is not |
| |
| |
>-----------------------------------------------------------------------------------------------------------------|
Good point...
Pointcuts are indeed not restricted by Java's access rules in what
they see. Otherwise, pointcuts would pick out code inconsistently
(not based on their specifications) and some crosscutting behavior
which was intended to be advised would not be. [Gregor I'm
sure has a better way of saying this.]
Java's access rules still apply to code (including code in
the if() PCD and in other code-things in the aspect, like
methods, initializers, constructors...), unless the aspect
is declared privileged.
Since advice can affect and skip private methods, which
most programmers consider as effectively final, it's not
clear that affecting final classes is any worse.
I personally found it a bit more surprising.
Wes
mmonteiro@xxxxxxxxxxxxxxxxx wrote:
> More than advice on final methods, it permits advice on private methods.
> For instance, in the code below non-privileged aspect Peeping can delete
> the behaviour of the call to private method Capsule.hidden(int) and
> capture its argument:
> ----------------------------------------------------------
> public class Capsule {
> private void hidden(int dummy) {
> System.out.println("I should be safe here...");
> }
> public void test() {
> hidden(17);
> }
> }
> public aspect Peeping {
> pointcut privateCalls(): call(private void *(..));
> pointcut call2Hidden(int arg): privateCalls() && args(arg);
> void around(int arg): call2Hidden(arg) {
> System.out.println("No, you're not safe: (" + arg + ").");
> }
> }
> public class TestAccess {
> public static void main(String[] args) {
> Capsule capsule = new Capsule();
> capsule.test();
> }
> }
> ----------------------------------------------------------
> However, if I try to call Capsule.hidden(int) from within the Peeping's
> around() advive, I get error
> "The method hidden(int) from the type Capsule is not visible".
> Someone correct me if I'm wrong, but doesn't the privilege affect only
> the "pure-Java" parts of aspects (i.e. code inside advice)? It doesn't
> seem to have any effect on the semantics of pointcuts and other
> aspect-specific parts.
>
>> AspectJ permits you to add members to final classes and advise
>> various join points whose static shadows are in final classes
>> without specifying that the aspect is privileged.
>> Do folks think:
>> a) this is ok as-is
>> i) but we should implement XLint messages for this
>> b) this should only work for privileged aspects
>> c) this should only work when you have the source
>> code for the final classes
>> d) only non-public members {or some other subset} is ok
>> because users of them know about the aspect
>> e) this should never work
>> Consider also:
>> - We permit advice on field-set join points where the
>> field is final, and advice on the method-execution of
>> final methods.
>> - Respecting final means that the AOP programmer who is working
>> on system issues can't implement a system-wide concern that
>> might not have been forseeable on the part of the programmer
>> of the final class, and in any case is not the responsibility
>> of the final class.
>> - We'd like to be able to say things like, "AspectJ respects
>> Java's modularity unless you explicitly declare an aspect
>> privileged," in order to have a clean policy that address this
>> concern of newcomers.
>> - We can write an XLint message so people can decide for
>> themselves whether it is ignored, a warning, or an error.
>> Thanks -
>> Wes
>
>
> Miguel J. T. Pessoa Monteiro
> Ph.D. student Minho University,Portugal
> eMail: mmonteiro@xxxxxxxxxxxx
> URL:http://gec.di.uminho.pt/mpm/
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
