Re: [aspectj-users] Annotations AspectJ questions

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Ron,

It is understandable that developers
will be concerned about the affect aspects will have on their code, particularly
if they feel they will be responsible for any bugs that may result from
weaving. However the approach you suggest will do nothing to promote trust
and because it is tantamount to putting up fences and may in general cause
as many problems as it tries to solve. This is because an aspect may be
excluded from advising certain join points which may be necessary for its
proper function. The resulting program will be incorrect and difficult
to debug. 

A better approach is to use annotations
as a way of defining the contract between code and aspects rather than
a series of "Keep Out" signs. This works better for some aspects
than others. For example to apply a Java 2 security mechanism developers
would add an @Permission annotation:

public class HelloWorld {
        
        @Permission("print")
        public void println()
{

           
    System.out.println("Hello World");
        }

        public static
void main(String[] args) {
           
    HelloWorld hello = new HelloWorld();
           
    hello.println();
        }
}


allowing you to use the following aspect:

public aspect SecuritySupport {

        before (Permission
p) : execution(@Permission * *(..)) && @annotation(p) {
           
    SecurityManager sm = System.getSecurityManager();
           
    if (sm != null) {
           
            sm.checkPermission(new
HelloPermission(p.value()));
           
    }
        }
        
}

public class HelloPermission extends BasicPermission
{

        public HelloPermission
(String action) {
           
    super(action);
        }
}

One place where exclusive rather than
inclusive annotations can be used is with tracing aspects. Here using @Exclude
can be used to ensure certain methods or classes are not traced either
because too much data is produced or sensitive information would be exposed.
In this case it is not misleading because when an entry is missing from
the log it is obvious why.

In the long run AOP will only work in
your project if everyone thinks it's a good idea. This doesn't mean everyone
has to understand how to use it, at least not initially, but they have
to benefit. This will be difficult if you start from a position of using
annotations to defend code against aspects.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) 
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

Please respond to aspectj-users@xxxxxxxxxxx

Sent by:        aspectj-users-bounces@xxxxxxxxxxx

To:        aspectj-users@xxxxxxxxxxx
cc:        
Subject:        [aspectj-users] Annotations AspectJ questions


Hi all!

Another newbie question.  After scanning the docs, I'm a little confused
on the capabilities of annotations.  I'm trying to employ aspects as a
part of a broader project, some of whom's members are quite suspicious
of granting the ability to crosscut their code without they're explicit
knowledge embodied in their code.  Equally,  I've been required to use
the annotation style for my poincuts and advice as the result of the
build process issues around utilizing the aspectJ syntax directly.

I've successfully used the  annotation style for the pointcuts and
advice declarations themselves, but I'm teetering on the brink of
understanding as to the use of annotations in the body of the code that
is to be cut.  Before I proceed down this road, I wanted to confirm that
one can concurrently employ annotations for both the advice declaration
as well as pointcut discrimination.  So given something that currently
looks like this:

class C {
   public void doIt() {...}
}

@Aspect class A {
   @Before("call(void C.doIt())") { ... }
}

Is there a prescription (at least by enforcing conventions) for being able to annotate Class C,such that:

A) The developer of C will know that an aspect has been applied
B) The developer of C will know (and by convention limit) the style of aspect applied
C) The developer of A can not add a pointcut unbeknownst to the owner of C (without at least violating conventions)

thus if I had created a BeforeOnly & AfterOnly annotation:
class C {
   @BeforeOnly @AfterOnly
   public void doIt() {...}
}

What would the syntax for the aspect look like?
@Aspect class A {
   @Before("???????") { ... }
}

Would there be a methodology to actually restrict the application of an @AfterReturning?
I recognize that some of these notions might be outside the spirit of AOP/aspectJ, but having to deal with real world resistence to AOP is a part of the equation.

Thanks in advance for the 'advice'  ;-) !

=Ron=





_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users