@AspectJ in Full: Pointcut Expressions and Five Advice Types

Plain words first. Your business code keeps growing the same pile of chores that have nothing to do with business: logging, timing, permission checks, alerts. Left alone, that code has to be hand-copied into every method — dozens of methods, dozens of copies, and one rule change means a project-wide hunt. An aspect does exactly one thing: pull those repeated chores out of the methods, write them once, and let the container slip them around the call at runtime. The business method does not change a single character and never learns it was wrapped.

To use this you must separate five terms. A join point is the moment of one real method invocation; a pointcut is an expression that decides "which join points are mine"; advice is the extra code you actually want to run; an aspect is the class packaging pointcut + advice; weaving is the act of attaching that advice onto the call path. Their relationship in one sentence: an aspect = where to intercept (pointcut) + what to do once intercepted (advice), and weaving connects them to the call.

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

• What does each symbol in execution( com.example.service...*(..)) control, and what breaks if you drop one dot?
• Which advice enters first and leaves last among the five, and why can only @Around rewrite the return value or swallow an exception?
• What are the four usual causes of a silently dead aspect, and what is the first thing to look at so you know it is not your imagination?

Before writing an aspect you must flip the switch. In plain Spring it is usually this line:

Pointcuts are the part that needs the most practice. The core is execution, whose full syntax is best remembered as a skeleton:

Only "return type, method name, parameters" are required; the rest can be omitted or replaced with * and ... These five examples cover the vast majority of everyday cases:

Beyond execution there are designators for "lazier" scenarios; they differ in the dimension they match:

Several pointcuts can be joined with logical operators, reading almost like prose:

Advice is the code inserted at the join points a pointcut matches. Spring AOP offers five, and the crux is their "permissions":

In one line: only @Around is the all-rounder. It receives a ProceedingJoinPoint, so it can change arguments, decide whether to invoke the target, rewrite the return value, or even swallow exceptions. The other four can only "observe" and "record".

That sentence is what this picture argues: the left side may look at everything and touch nothing, the right side can touch everything and therefore owns the consequences. The selection rule is never "which one is more advanced" but "does this job need to change the outcome":

How does an advice method get "information about the current call"? Through parameter binding. Here is a complete aspect class:

Here is how that name-matching actually happens, in six frames. Watch frame ④: the string in the annotation and the parameter names are compared one by one — no expression language is involved at all, it is literally names:

Because no expression language is involved here, plenty of beginners assume returning = "result" and the #{} inside @Cacheable(key = "#user.id") are the same syntax, and then write horrors like returning = "#result", which fail in silence. That other thing is SpEL, a separate language: it has its own root object (#root / #this), collection selection and projection, ternary and safe-navigation operators, and completely different failure messages. The last mode shows the three classic miswrites side by side:

With all advice attached to one method, what is the order? Run it once and the output is clear:

When several aspects match the same method, order is decided by @Order:

"My aspect is written but never runs" is the number one aspect problem. Walk this table line by line and you will locate it eighty percent of the time:

The first tool is always logging: set logging.level.org.springframework.aop=DEBUG and the container prints which aspects and proxy type each bean received, with a "does not match" reason when a pointcut misses.

The demo below visualizes the advice chain's execution order. Switch to the "exception path" and run it again to see how @AfterThrowing replaces @AfterReturning and how @After runs on both paths:

That one shows how the proxy forwards; the ordering table in Section 6 deserves a demo that is about ordering itself. advices hangs all five advice types on one method — run normal, then error, and the difference between the two paths shows up immediately:

Everything above was prose; this section is all clickable. The four demos follow "see the symptom, then the mechanism, then the order", and each lets you switch parameters.

The first answers the parcel sorting analogy from Section 0: the same package text means different things inside execution and within. Pick "execution parts" to watch segment-by-segment matching; pick "Why nothing matched" for the five causes of silent misses — the one beginners stall on hardest, because it raises no error at all:

Animation is still too quick for "check it slot by slot". Spread the same evaluation over a stepping bench: a candidate method and one expression on the left, "which slot is being judged right now, and with what verdict" on the right. Press next and watch step ⑤ — the whole expression has already short-circuited here; the last two slots were never even evaluated:

The second settles "does the annotation go on the method or the class". @annotation and @within differ by one word yet behave oppositely, and this branch also names an invisible killer: Java does not inherit method annotations onto the implementing class, so annotating only the interface method usually matches nothing:

The third is the before-versus-after weaving contrast: the very same userService.save("Alice") call has one stack frame and a body mixed with logging, try/catch and timing when no aspect exists; once woven, three cross-cutting layers wrap it while the business code is unchanged by a single line. Switch to "What it costs" to see the price of that case (slower startup, and four cases nothing can advise):

The fourth resolves the question left open at the end of Section 6: when several aspects hit one method, who sits outside. "Nested timeline" lists the full chain step by step (Around1-before → Around2-before → Before → target → AfterReturning → After → Around2-after → Around1-after); "Reversed order" shows why forgetting @Order turns into "fine on my laptop, red in CI":

Four demos done; what remains is turning "read an expression" into "say instantly who it catches". The table in Section 2 sorts designators by dimension; this round trains something different — expression in, coverage out — and since no two entries on either side repeat, position tricks will not save you:

From here, type the commands yourself. This console talks to the same container running in your browser, and every line of output is computed by the kernel — boot, then beans to see who got a shell, and lab pointcut nomatch is the full version of the stepping bench above:

On the left, change the four slots one at a time — return type, package depth, method name, argument list; on the right you immediately get which methods this matches and why the rest are missed. Choosing the "dropped a dot" and "() mistaken for (..)" cells once by hand beats memorising ten rules:

Every "error text" below can be pasted verbatim into a search box — do not paraphrase it:

Row one of that table fails in silence, but a malformed pointcut has the opposite fate: it explodes in your face, with a stack whose upper frames belong to Spring while the actual culprit sits inside AspectJ's parser. Practise on it:

Goal: in three minutes, produce a complete aspect whose logs you can actually see, confirming AOP works in your project. Drop these files into a fresh Spring Boot project (the build needs spring-boot-starter-aop, or at least spring-boot-starter plus org.aspectj:aspectjweaver).

Expected output (the ==== line comes from System.out, the rest from slf4j, whose prefix carries the timestamp and logger name):

Change exactly one thing each time and read the conclusion:

1. Turn the pointcut into com.example..Service.(..) (drop one dot). You will observe: UserService still matches while it sits directly in com.example, but the moment it moves into com.example.service.impl every advice dies, silently. Compare with the one-star cell of Section 12 and "a single eats one level" becomes obvious.
2. Delete return pjp.proceed(); from the @Around and keep only the logging. You will observe: the ==== target method runs ==== line disappears entirely and the result becomes null, while the program throws nothing at all. That is the live version of the second quiz in Section 14.
3. Add a second MetricAspect on UserService#save with @Order(2) (same body, prefix [METRIC]) and mark TraceAspect @Order(1). You will observe the sequence AROUND-IN(Trace) → AROUND-IN(Metric) → BEFORE → target → AFTER → AROUND-OUT(Metric) → AROUND-OUT(Trace); swap the two numbers and both entry and exit flip as a block. Now delete both @Order annotations and restart a few times — the order begins to drift, which is precisely how ghost bugs are bred.
4. Make save private. You will observe: all advice vanishes again, still with no error. See the proxy boundaries in #14 AOP internals.

Build a slow-call attribution aspect: not just timing, but tiered by threshold and aggregated.

• Define @SlowWatch(value = "place order", warnMs = 200, errorMs = 1000) with @Target(METHOD) and @Retention(RUNTIME)
• Write @Around("@annotation(slowWatch)"): INFO on the normal path, WARN past warnMs, ERROR past errorMs, always including method name, the annotation's value, elapsed time and argument count
• Accumulate per-method call counts and total time in a ConcurrentHashMap<String, LongAdder>, and print a "Top 3 slowest methods" summary (via @Scheduled or on shutdown)
• Never swallow: catch, record a failure count, then rethrow the original

Acceptance checklist: ① drive one method to 50ms / 300ms / 1200ms and see INFO / WARN / ERROR respectively; ② on an exception the caller still receives the original throwable (verify with @AfterThrowing or a try/catch that the stack was not replaced); ③ annotate a private method with @SlowWatch and explain in your own words why nothing happens without guessing; ④ remove @Component from the aspect and confirm business output is byte-for-byte identical — proof it really is only a case slipped over the phone.