Bug 266381

Description Ramnivas Laddad 2009-02-26 16:48:23 EST

(I thought we had an issue related to this, but couldn't find one).

I come across many situations, where the let() pointcut (http://abc.comlab.ox.ac.uk/documents/abc-2006-1.pdf) would have helped a lot in creating a simpler design.

A common situation under which I encounter the need for the let() pointcut is where I want the base aspect to make no decisions regarding the join point selection criterion. Subaspects then are free to use an annotation-based or name-based pointcut. However, defining the pointcut in the base aspect is challenging. The let() pointcut will let me do a better job.

abstract aspect AbstractSecurity {
    abstract pointcut secured(String role);

    before(String role) : secured(role) {
       ...
    }
}

aspect AnnotationDrivenSecurity extends AbstractSecurity {
       pointcut secured(String role) 
           : execution(@Secured * *(..)) && @annotation(Secured(role));
}

aspect MappingBasedSecurity extends AbstractSecurity {
    Map<String, String> roleMapping; // injected dependency

    pointcut secured(String role)
           : execution(@Secured * *(..))
             && let(role, roleMapping.get(thisJoinPointStaticPart.getSignature());

    /* or more likely something like:
    pointcut secured(String role) : execution(@Secured * *(..)) && let(role, getRole(thisJoinPoint));

    String getRole(JoinPoint jp) {
       ...
    }
    */
}

This way the abstract aspect declares what it absolutely needs and no more. Currently, I end up using the template design pattern, where the base aspect calls a method such as getRole(JoinPoint). For the mapping based subaspect, this is fine. However, for the annotation-based approach, this means using reflection on the thisJoinPoint object.