Inside Spring AOP: The Auto-Proxy Creator

The previous article covered how to write an aspect; this one answers a single question: you only added an @Aspect, so why did the container swap your bean for a proxy? Who swapped it, and at which step? The answer is one long-named component, AnnotationAwareAspectJAutoProxyCreator, and the whole article unpacks its four moves: it is a post-processor → it collects candidate advisors → it evaluates each pointcut → on a hit it builds a proxy and replaces the original object.

First, pin down the five terms for someone who has never written Java. A BeanPostProcessor is a hook the container inserts around every bean it creates — just two methods, yet its return value can replace that bean. An Advisor is a paired object of "pointcut + advice", the unit Spring actually works with internally; your @Aspect gets split into several advisors at startup. A pointcut is the expression deciding "does this method's signature belong to me". Target versus proxy: the target is the raw instance you constructed, the proxy is the shell wrapped over it, holding the target inside. Weaving is the act of attaching advice onto the call path — Spring AOP weaves by building a proxy at runtime.

After this section you should be able to answer three questions:

• At which step of the bean lifecycle is the proxy created, and why does that step explain "no advice fires when I call my own methods from @PostConstruct"?
• How does one @Aspect class get split into advisors, and what does an empty candidate list imply?
• When you see Cannot proxy final class or Bean is not yet fully initialized, which station on the timeline above should you inspect?

Last section we took the proxy factory down to DefaultAopProxyFactory, but the last question remains unanswered: who creates the proxy, and when? You have written your @Aspect and checked the pointcut, yet how does the container know to swap a bean for a proxy at all?

The entry point is the very annotation we habitually add.

Now we must state its real identity: AnnotationAwareAspectJAutoProxyCreator is not an active scanner but a BeanPostProcessor — it does not create beans; it "sticks a hand in" while other beans are being created. More precisely, it also implements BeanFactoryAware, because it needs the BeanFactory to reach other beans in the container.

Peel that long name apart and every layer of capability comes from a clear interface:

Read bottom-up and it is a path of growing capability: from "receiving callbacks" to "sensing the bean", to "replacing the bean with a proxy". That is exactly why Spring uses a BeanPostProcessor as the hook — it only needs to attach one callback to the standard lifecycle, without rewriting container creation.

The main entry is postProcessAfterInitialization, which immediately calls wrapIfNecessary:

• The first gate is caching: advisedBeans remembers "does this class need a proxy", so pointcut evaluation is not repeated per bean
• The second gate is infrastructure classes: the creator itself, Advisor and Pointcut are excluded to avoid self-entanglement
• The third gate is getAdvicesAndAdvisorsForBean: the real "find advisors" step, which internally calls findEligibleAdvisors to filter candidates down to those matching this class
• On a hit, createProxy hands off to ProxyFactory, which builds the proxy and returns it to the container

findEligibleAdvisors is no mystery — it simply "takes all candidates, then tries each against the pointcut":

At this point the two timelines deserve to be separated: the left column below happens at startup, exactly once per bean; the right column happens on every single call. Sections 9 and 11 are all about the right column, while the dead-aspect checklist in Section 6 lives almost entirely in the left one:

The AspectJ part of the candidate advisors comes from ReflectiveAspectJAdvisorFactory, which the creator delegates to. It walks the aspect's methods and picks out the ones with advice annotations:

On a hit, createProxy delegates to ProxyFactory. Its inheritance chain is short, and the real capability lives in the parent AdvisedSupport:

"My aspect is written but does absolutely nothing" is the number one problem. Walk this table and you will locate it eighty percent of the time:

The first tool is always logging. Turn on AOP DEBUG and the creator prints which advisors each bean matched and which proxy type it used; when a pointcut misses, it writes the exact "does not match" reason. That is far faster than staring at an execution expression and guessing.

Many people conflate Spring AOP with AspectJ, but they are two mechanisms:

One-line distinction: Spring AOP is "proxy-level cross-cutting", AspectJ is "bytecode-level cross-cutting". Everyday business work is fine with Spring AOP; you only need AspectJ weaving to intercept private methods, field access, or non-container objects.

The demo below visualizes both proxy creation and advice-chain assembly. Switch the proxy type, watch "who wraps whom", and feel the order of the chain:

Once the proxy exists, how does the chain actually run? This mode hangs all five advice types on one call, and you will see they are really five elements of a list, not a sentence about ordering:

The animation gives the overview first — how the cursor climbs from 0 to the end of the list and then unwinds:

Setting a real breakpoint is what makes "first in, last out" click: it is not a rule, it is the inevitable shape of recursion. Below are the relevant internal lines as a stepping bench, with currentInterceptorIndex refreshed on the right — every increment lets one advice layer in; only when it reaches the list length does the target method appear:

This section turns all five chains above into things you can click. The core is the four branches of autoptr (the auto-proxy creator); take them in order, because they map onto the four stations of the timeline.

Station one: at which step the proxy is born. This branch shows it hangs off "after initialization", i.e. step six of article nine, and explains why a cycle takes a different entry point, getEarlyBeanReference:

Station two: the verdict "is it worth wrapping". findEligibleAdvisors → shouldWrap → the advisedBeans cache all live here, and it also explains the oddity "I changed the getBean order and the proxy disappeared":

Station three: the factory that actually builds it — the three parts inside ProxyFactory, how the class only materialises at getProxy(), and how proxyTargetClass=true forces CGLIB with a chain of knock-on effects:

Station four is the one people skip: who stands behind the proxy. The default SingletonTargetSource always returns the same bean, but a pool or prototype gives a fresh target per call; meanwhile Object's toString/equals/hashCode are always answered by the proxy itself and never advised — which is exactly why "two business-equal proxies count as two entries in a HashSet":

The creator alone is not enough — put it back into the whole assembly line and into the concrete match. The first demo runs a bean from instantiation all the way to after-initialization so you see where the proxy gets inserted; the second proves that matching happens per method, since the same package text means different things in execution versus within; the third shows how the proxy type is chosen and why self-invocation bypasses all of it:

Station five goes back to call time: where several aspects sit inside one interceptor list. "Nested timeline" enumerates it frame by frame (Around1-before → Around2-before → Before → target → After → Around2-after → Around1-after), which is exactly the multiplayer version of the stepping bench above:

The kernel class names are the intimidating part, yet each maps onto exactly one job. Pair these seven regulars of stack traces and DEBUG logs — a wrong match tells you which station of the timeline you mixed up:

From here, type the commands yourself. This console is attached to the same in-browser container and every response comes from the kernel — walk the timeline station by station:

On the left, set the proxy strategy, the shape of the target class, and whether an interface exists; on the right you immediately get "which proxy, which type may you inject, and which limit will you hit". These three switches cover the entire comparison table in Section 5:

Each fragment below can be pasted verbatim into a search box; the last column points back to the timeline in Section 11 so you know which station to inspect:

The aggravated version of that trap blocks startup outright, and its message mixes AOP vocabulary with circular-dependency vocabulary, which makes it look far worse than it is. Practise — and note the guilty frame is not the top one:

Goal: bypass @Aspect entirely and drive the auto-proxy creator with your own Advisor bean, while printing its decision process. Do this once and "an advisor = pointcut + advice" and "empty candidates means no proxy" stop being slogans.

Add this line before starting, otherwise the creator's decisions stay invisible:

Expected output (timestamps and prefixes elided):

1. Replace the pointcut with new ExecutionPointcut("com.example.internals...(..)"). You will observe: ping() now prints [advisor] too — the same advisor, only a different "where to grab", with the advice body untouched.
2. Make ReportService a final class. You will observe: startup throws BeanCreationException: ... Cannot proxy final class, matching row one of Section 13.
3. Keep CGLIB but fetch the bean by its concrete type. You will observe: still fine. Now set spring.aop.proxy-target-class=false and extract an interface for ReportService, then receive it as the implementation class — ClassCastException appears, the live version of the sandbox cell auto|iface|by-impl.
4. Add a method self() inside ReportService that calls this.build("x"). You will observe: no second [advisor] line, because this is the raw object. This is the one limit in this article that lives at call time rather than creation time.

Build a proxy health report: once the app is ready, automatically state which beans are proxied, with which proxy kind, and which advisors hit them.

• Implement an ApplicationListener<ApplicationReadyEvent> (or use SmartInitializingSingleton) and walk beanFactory.getBeanDefinitionNames()
• For each bean call beanFactory.getBean(name) and classify with AopUtils.isAopProxy(bean) / isCglibProxy / isJdkDynamicProxy
• For proxied ones, print the simple names from ((Advised) bean).getAdvisors(); catch exceptions per bean, record the name and continue so one failure never aborts the report
• Emit a summary table: total / CGLIB count / JDK count / top 5 advisors by hits, and skip everything when spring.aop.report=false

Acceptance checklist: ① the numbers agree with a manual count from logging.level.org.springframework.aop=DEBUG; ② comment out one @Aspect's @Component and its advisor vanishes from the report while business output is unchanged — proof that empty candidates mean neither a proxy nor an error; ③ you can use the report to explain to a colleague why their service class name grew a $$SpringCGLIB$$ tail; ④ the report itself triggers no extra eager bean creation (no new Creating shared instance lines appear because of it).