AOP Model & the @AspectJ Style

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.

It's a BeanPostProcessor, so Spring runs it after each bean is created. In postProcessAfterInitialization it checks if any aspect's pointcut matches the bean; if so it returns an AOP proxy that wraps the bean instead of the raw object.

Inside aop:config, add <aop:aspect ref="bean">. Declare a named <aop:pointcut id="..." expression="..."/>, then attach advice like <aop:before pointcut-ref="..." method="..."/>. Each advice element names the POJO method and the pointcut to match.

Within one aspect, advice runs in a fixed precedence by type: @Around, then @Before, then @After, @AfterReturning, @AfterThrowing. But two advices of the SAME type at the same join point have undefined order — you cannot rely on method declaration order.

An introduction adds a new interface (and a default implementation) to advised beans. @DeclareParents declares which interface to add, which beans get it, and which class implements it, so the proxy now implements that extra type.

It configures aspects in XML instead of with @Aspect annotations. The aop:config element (from the aop namespace) holds aspect definitions; Spring reads it and wraps matching beans in proxies that run your advice.

By default an aspect is a singleton: one shared aspect instance for the whole application context, just like an ordinary singleton bean. So any fields in the aspect are shared across all advised objects and all threads.

Spring Boot enables it automatically via AopAutoConfiguration when aspectjweaver is on the classpath, so you normally don't add @EnableAspectJAutoProxy. In a plain Spring app you must add the annotation yourself.

Put @DeclareParents on a field in an @Aspect. The field's type is the interface to introduce, value is an AspectJ pattern for target beans (e.g. "com.example.service.*+"), and defaultImpl is the class implementing that interface.

Combine named pointcuts inside another @Pointcut (or advice) expression with && (both match), || (either matches) and ! (negation). Example: @Pointcut("serviceMethods() && !readOnlyMethods()").

Use <aop:around pointcut="..." method="..."/>. The referenced POJO method must take a ProceedingJoinPoint as its first parameter and call proceed() to run the target. Its return value becomes the method's result.

perthis creates a new aspect instance for each unique object executing a matched join point (each unique 'this'/proxy); pertarget creates one per unique target object. Both are non-singleton, so the aspect bean must be declared with prototype scope so Spring can create multiple instances.

Weaving is linking aspects into your code so advice actually runs. The target object is the real bean being advised. Spring weaves at runtime by wrapping the target in a proxy; AspectJ can weave at compile time or class-load time.

proxyTargetClass=true forces CGLIB class proxies instead of JDK interface proxies. exposeProxy=true publishes the current proxy via AopContext.currentProxy() so a bean can call its own advised methods through the proxy instead of bypassing it.

You hold the proxied bean reference and cast it to the introduced interface, then call its methods. The state lives in the defaultImpl instance that backs the proxy — typically one instance per advised bean — not in the original target object.

Use the fully-qualified reference: ClassName.pointcutName() (or the full package path). The pointcut method must be visible enough — make it public (or protected/package-private) so other aspects can reference it; a private @Pointcut is only usable inside its own class.

aop:advisor pairs a pointcut with a reusable advice bean that already implements a Spring Advice interface (like MethodInterceptor). aop:aspect instead groups multiple advice methods on a plain POJO. Advisors are how tx:advice transactions get applied.

Order whole aspects with @Order or by implementing Ordered — lower value = higher precedence, runs first on entry. This is the ONLY way to get deterministic ordering, because two same-type advices inside one aspect are unordered. So split advice that must be ordered into separate, @Order-ed aspects.

Use aspects for truly cross-cutting, orthogonal plumbing (transactions, security, metrics) that would otherwise be duplicated everywhere. Keep business rules in explicit code. Over-using AOP hides behavior, complicates debugging, and creates 'action at a distance'.

Both are proxy-based Spring AOP using the same AspectJ pointcut language and produce identical proxies. XML keeps advice metadata outside the class (good for third-party beans or externalized config); annotations keep it cohesive. XML supports only singleton aspects; @AspectJ also supports perthis/pertarget.

An introduction adds a whole new interface and its implementation to an existing object, so the advised bean gains extra methods it never declared. Advice only wraps behavior around existing method calls; introduction adds new capabilities.

Yes. The @Pointcut method's parameters become the pointcut's parameters. Binding designators like args(), this(), target() and @annotation() tie a matched value to a named parameter, and advice with the same parameter names receives that value.

Because proxying happens in a BeanPostProcessor after init, any bean created before that processor is active — like other BeanPostProcessors and their dependencies — won't be proxied. Aspects and AOP infrastructure beans are also skipped by design.

Use an introduction to give many beans a uniform interface/capability without editing each class — e.g. change-tracking. Prefer plain interfaces or composition when you can edit the classes. Spring can only introduce interfaces via proxies; full AspectJ weaving can add fields and methods to the class itself.

Centralize shared selections in one or a few public @Pointcut declaration classes (a CommonPointcuts library), give each an intent-revealing name, compose smaller pointcuts into bigger ones, and keep raw designators out of advice. Watch package-based expressions that silently stop matching after refactors.