Spring AOP can only be applied to Spring-managed components/beans, not to non-Spring POJOs. If you want to apply AOP to non-Spring classes you need AspectJ, not a proxy-based “AOP lite” framework like Spring AOP. For more information about how to use AspectJ (which does not need Spring at all) in combination with Spring and how … Read more
The previous solution is too invasive as it not only creates advice on the fly but also handles advising beans. This replicates functionality of Spring’s AbstractAdvisorAutoProxyCreator, specifically the getAdvicesAndAdvisorsForBean method, where Spring will locate and apply eligible Advisors to each bean. A better approach is to simply programmatically create Advisors and let Spring handle the … Read more
Regular Spring @Components For an explanation of how normal Spring (AOP) proxies or dynamic proxies (JDK, CGLIB) in general work, see my other answer with illustrative sample code. Read that first and you will understand why self-invocation cannot be intercepted for these types of proxies via Spring AOP. @Configuration classes As for @Configuration classes, they … Read more
I believe you have to implement an around advice, instead of a before advice. Because you can use proceed with your new arguments: proceed(newArgs);
Although the OP heavily relied on AspectJ solutions, the question as it stands doesn’t directly suggest that solutions should be limited to AspectJ. Therefore I’d like to offer a non-AspectJ way to advise a Spring Data JPA Repository. It is based upon adding a custom Interceptor into barebone Spring AOP proxy interceptor chain. First, configure … Read more
This is a limitation in Spring AOP. When you use AspectJ pointcuts to weave aspects into beans, Spring will use CGLIB to generate a subclass of the target, and invoke the aspects from that subclass. If the target class does not have a public default constructor, however, this will fail. CGLIB does have the ability … Read more
You cannot bind an argument at an arbitrary position via args() in AspectJ because this could lead to ambiguity. Just imagine you have two or more parameters of the same type (or annotated by the same annotation type in this case). Which one of them should be bound to the named args() parameter? So while … Read more
As long as you have control of your AOP I think it’s efficient. We did have performance problems anyway, so by own reasoning we were not fully in control 😉 This was mostly because it’s important that anyone that writes aspects has full understanding of all the other aspects in the system and how they … Read more
I think what you are trying to test is aspect weaving and pointcut matching. Please note that that would be an integration rather than a unit test. If you really want to unit test your aspect logic and because you have tagged the question by “mockito” anyway, I suggest you do just that: Write a … Read more
Andy Brown is right, it is by design. The reason is that according to the AspectJ manual pointcut designators such as @args, @this, @target, @within, @withincode, and @annotation (or the subset of those available in Spring AOP) are used to match based on the presence of an annotation at runtime. This is why in the … Read more