Aspect-Oriented Programming

Put @Aspect on the class to mark it as an aspect, and also register it as a Spring bean (e.g. add @Component so it is scanned). Then enable AOP with @EnableAspectJAutoProxy (Spring Boot does this automatically).

A cross-cutting concern is a responsibility (like logging, security, transactions) needed by many parts of an app but not part of any one's core job. AOP pulls that repeated code into one place instead of copying it everywhere.

It turns on Spring's support for @AspectJ-style aspects. Spring then scans for @Aspect beans and automatically wraps matching beans in proxies so the aspect's advice runs around their methods.

A named pointcut gives a pointcut expression a name so you can reuse it. You declare it by annotating an empty, void-returning method with @Pointcut("...expression..."); the method name becomes the pointcut's name.

An aspect is the module holding a cross-cutting concern. A join point is a point where code could run (in Spring, a method call). A pointcut is an expression selecting which join points. Advice is the code that runs at those matched points.

@annotation(SomeAnnotation) matches any method-execution join point where the method being called carries that annotation. Unlike execution()/within(), which match by name or package pattern, @annotation matches by the presence of an annotation on the method.

args() matches join points where the method's arguments are of the given types at runtime. execution() matches on the static method signature. args() checks the actual runtime argument types and can also bind an argument into an advice parameter.

bean(name) limits advice to join points inside Spring beans whose bean name matches the given pattern. For example, bean(tradeService) advises only the bean named tradeService, no matter its type.

execution() matches method executions. That expression means: any public method, returning any type, in any class inside com.app.service or its sub-packages, with any name and any number of arguments.

Only method executions. Spring AOP wraps beans in proxies, so an aspect can run before/after/around a public method call on a Spring bean — but not field reads/writes, constructors, or static blocks.

@After is advice that runs after a matched method finishes — whether it returned normally or threw an exception. It behaves like a finally block, so it is used for cleanup. It cannot see the return value or the exception.

@AfterReturning is AOP advice that runs after an advised method finishes successfully (returns normally). It does NOT run if the method throws an exception. It can read the returned value but cannot replace it.

@AfterThrowing is an aspect advice method that runs only when the matched method (join point) exits by throwing an exception. If the method returns normally, it does not run.

@Around wraps a method call. It runs code before and after the target method. You must call proceed() to actually run the target method; if you skip it, the target never executes and you return your own value instead.

@Before advice is aspect code that runs before a matched method (the join point) executes. It's used for things like logging entry or validating arguments. It runs before, then the real method still runs.

Spring advice like @Transactional lives on a proxy that wraps the bean. When one method calls another via this, the call bypasses the proxy, so no advice runs. Setting exposeProxy=true lets a method fetch the proxy and re-route the call so advice still applies.

A CGLIB proxy is a runtime-generated subclass of your target class that overrides its methods to add behavior like transactions. Unlike a JDK dynamic proxy, it doesn't need the class to implement an interface.

A JDK dynamic proxy is a class the JVM builds at runtime that implements the same interface(s) as your bean and forwards calls to it. Spring can only create one if the target implements an interface.

MethodInterceptor is Spring's low-level 'around' advice. Its invoke(MethodInvocation) method runs your code, then calls invocation.proceed() to invoke the real target method, and can run more code after — like a wrapper around each call.

In plain Spring's default: if the bean implements at least one interface, Spring makes a JDK dynamic proxy; if it implements no interface, Spring uses CGLIB, which builds a subclass at runtime. Spring Boot changes the default to always use CGLIB.

Spring AOP can only intercept public or protected, non-final instance methods. Final methods, private methods, and static methods are not advised, so annotations like @Transactional or @Async on them silently do nothing.

Spring AOP only intercepts method executions on Spring beans. It cannot advise field reads/writes, constructors, static methods, or private methods — because it works by wrapping the bean in a proxy object.

When a bean calls its own method via this.method(), the call goes straight to the real object, not through Spring's proxy. Because advice like @Transactional lives on the proxy, it is skipped, so no transaction starts.

Because @Transactional is applied by the proxy. When a bean calls its own method with this.method(), the call goes straight to the target and skips the proxy, so the transactional advice never runs.

The lowest-value aspect is outermost, like the outer layer of an onion. On the way in, its @Before runs first. On the way out, its @After runs last. So before advice runs highest-precedence-first, and after advice runs highest-precedence-last (reversed).

Spring's @Transactional works through a proxy that wraps the bean. An internal call (this.method()) bypasses the proxy, so the transaction advice never runs. Only calls coming through the injected bean reference are intercepted.

Spring AOP adds cross-cutting behavior (logging, transactions, security) by wrapping a Spring bean in a proxy. The proxy runs your advice before/after the real method call. It works only on Spring-managed beans and needs no extra build step.

CTW can advise final methods, private methods, constructors, and self-invoked calls, and even objects created with new. It works because ajc edits the class bytecode directly, so there is no proxy boundary that calls must pass through to be intercepted.

Add @EnableLoadTimeWeaving on a config class, provide META-INF/aop.xml naming the aspects and packages to weave, and start the JVM with a java agent (-javaagent:spring-instrument.jar or aspectjweaver.jar) so classes can be transformed as they load.

Spring AOP advice runs in the proxy that wraps the bean. An internal call like this.save() goes straight to the real object and never touches the proxy, so the advice (transaction, cache, retry) is skipped. Fix: call through the proxy or use AspectJ.