Community
Participate
Working Groups
(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.
See bug #266415 for additional examples