🧠 The big idea in one line

Filters, interceptors, and aspects are three places to run code around a request — at three different depths of the stack.

Every web app has work that isn't the "real" job of any single endpoint: logging, timing, auth checks, adding headers, collecting metrics.
Copying that work into every controller method is a mess. You repeat it everywhere, and you forget it somewhere.
A cross-cutting concern is a job that applies to many requests or many methods — it cuts across your normal code instead of belonging to one spot.
Spring gives you three tools to handle these in one place. They differ by where in the request's journey they sit, and how much they can see.
You meet this the first time you need "run this before every request" — and immediately hit the real question: which of the three?

🛣️ First, the journey of one request

Before comparing the tools, you need to see the path a request takes. It does not land on your controller directly.

Servlet container (Tomcat, Jetty): the web server that speaks HTTP and hands your app a raw HttpServletRequest.
DispatcherServlet: Spring's single front-door servlet. It reads the URL, picks the right controller method, calls it, and turns the return value into a response.
Handler: the specific controller method chosen to serve this request.

Here is where each tool sits, from outside in:

HTTP request
  │
  ▼
▓ Servlet Filter            ← outermost · raw HTTP · no idea which controller
  │
  ▼
  ▓ Handler Interceptor     ← inside Spring MVC · knows the handler
    │
    ▼
    ▓ Controller method
      │  (calls a service bean)
      ▼
      ▓ AOP Aspect          ← wraps any bean method · fires for non-web calls too

The order is the whole insight: filters sit outermost, interceptors sit inside the DispatcherServlet, aspects sit deepest — around your bean methods.
As you move inward, each layer sees more Spring detail and less raw HTTP.

🧱 Layer 1 — Servlet Filters (the outer wall)

A Filter is part of the Servlet spec — plain Jakarta/Java EE, not Spring. It wraps the request before Spring even runs.
It sees the raw HttpServletRequest and HttpServletResponse, and nothing about which controller will run.

@Component
public class TimingFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        long start = System.currentTimeMillis();
        chain.doFilter(req, res);   // hand off to the next filter, then the app
        long took = System.currentTimeMillis() - start;
        System.out.println("Request took " + took + "ms");
    }
}

chain.doFilter(...) is the pivot. Everything before it runs on the way in; everything after it runs on the way out.
If you never call chain.doFilter, the request stops right here. That is how a filter blocks a request entirely — for example, rejecting a missing API key before any Spring code runs.
It holds both the request and the response, so it can even wrap or replace the response body.

Filters are good at:

Work that must happen for every HTTP request — controller-bound or not (static files, error paths).
Reading or modifying the raw request/response (compression, CORS headers, caching the request body).
Security gates that should run before Spring. Spring Security itself is built as one big filter.

🧭 Layer 2 — HandlerInterceptors (inside Spring MVC)

A HandlerInterceptor runs inside the DispatcherServlet, after Spring has already decided which handler will serve the request.
So it knows the handler — a filter never does.

It gives you three hooks around the controller call:

Hook	When it runs	Typical use
`preHandle`	before the controller method	auth check; start a timer; return `false` to block
`postHandle`	after the controller, before the view renders	tweak the model or response
`afterCompletion`	after everything, even when the handler threw	cleanup; stop a timer; log the exception

@Component
public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object handler) {
        if (req.getHeader("X-User") == null) {
            res.setStatus(401);
            return false;          // stop: the controller never runs
        }
        return true;               // continue to the controller
    }
}

Returning false from preHandle stops the request — the same idea as a filter that skips chain.doFilter, except you are already inside Spring.
You register it against URL patterns, and the handler argument lets you read the target method's annotations:

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new AuthInterceptor()).addPathPatterns("/api/**");
    }
}

Interceptors are good at:

Web concerns that need to know the controller or endpoint (per-route auth, request logging that names the method).
Anything tied to the MVC lifecycle, like touching the model before the view renders.

🎯 Layer 3 — AOP / Aspects (around any bean method)

The first two tools only see web requests. But cross-cutting work often lives deeper — inside services that are called from web endpoints and from scheduled jobs and from message listeners.

AOP (Aspect-Oriented Programming) lets you run code around any Spring bean method call, web or not.
How does it reach inside a method call? Spring wraps your bean in a proxy — a stand-in object that looks identical to your bean but runs extra code before and after the real method.

caller ──▶ [ Proxy ] ──▶ your real bean method
               │
               └─ runs "advice" before & after the real call

Two terms fall out of that picture:

Advice: the extra code the aspect runs (before, after, or around the method).
Pointcut: the rule that picks which methods to wrap — e.g. "every method in the service package".

@Aspect
@Component
public class LoggingAspect {
    @Around("execution(* com.example.service..*(..))")
    public Object logTime(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = pjp.proceed();      // call the real method
        long took = System.currentTimeMillis() - start;
        System.out.println(pjp.getSignature() + " took " + took + "ms");
        return result;
    }
}

pjp.proceed() is the AOP version of chain.doFilter — it runs the real method. Same in-and-out shape as a filter, but wrapped around a plain Java method instead of an HTTP request.
The pointcut execution(* com.example.service..*(..)) targets every method under the service package.

Aspects are good at:

Business-level cross-cutting: @Transactional, @Cacheable, retries, method-level security, a custom @Audited annotation.
Work that is not about HTTP at all — it fires no matter who called the method.

⚠️ Easy to confuse — the proxy gotcha (self-invocation)

Because AOP works through a proxy, calling one method of a bean from another method of the same bean skips the proxy — the advice does not run.
The reason: this.otherMethod() goes straight to the real object and never touches the wrapper.
This is the classic "@Transactional did nothing" bug: an internal call bypassed the proxy that would have opened the transaction.

🧩 Bad vs good: picking the wrong layer

❌ Putting per-endpoint auth in a Filter

A filter cannot see which controller method will run, so you end up re-parsing the URL by hand to decide the rule. Fragile, and it duplicates Spring's own routing.

✅ Use an interceptor (or method security) instead

It already knows the handler and its annotations, so the rule lives next to where the endpoint is defined.

❌ Using AOP to set an HTTP response header

Your service method has no HttpServletResponse — you would have to smuggle one in. Wrong layer.

✅ Use a filter or interceptor

They hold the raw response and can set headers directly.

⚠️ Easy to confuse — quick separations

Filter vs Interceptor: both wrap web requests. A filter is at the servlet level, has no idea which controller runs, and fires even for non-Spring requests. An interceptor is inside Spring MVC, knows the handler, and only fires for requests the DispatcherServlet routes.
Interceptor vs Aspect: an interceptor is web-only and lifecycle-based (pre/post/after). An aspect targets any method by pointcut and fires for non-web calls too.
The "continue" call in each: chain.doFilter(), return true, and pjp.proceed() all mean "go on to the next thing." Skip any of them and the flow stops there.

📊 Quick summary

	Filter	Interceptor	Aspect (AOP)
Level	Servlet container	Spring MVC (DispatcherServlet)	Any Spring bean method
Spec	Servlet (Jakarta)	Spring MVC	Spring AOP
Sees	raw request/response	handler + request/response	method args + return value
Knows the controller?	❌ no	✅ yes	it is a bean method
Fires for non-web calls?	❌ no	❌ no	✅ yes
"Continue" call	`chain.doFilter()`	`return true`	`pjp.proceed()`
Typical use	CORS, compression, security gate	per-endpoint auth, MVC logging	`@Transactional`, caching, audit

🎯 Decision rule

Need it for every HTTP request — even errors and static files — or must it run before Spring? → Filter.
Need to know which controller/endpoint runs, or hook the MVC lifecycle? → Interceptor.
Need it around service/business methods, or for non-web calls too? → Aspect (AOP).
Rough guide: outer = HTTP plumbing, inner = business logic. Pick the outermost layer that still has everything you need.

💡 Remember this

Three layers, outer to inner: Filter → Interceptor → Aspect. Each sees less raw HTTP and more Spring/business detail.
The "continue" step is the heart of all three: chain.doFilter / return true / proceed(). Skip it to stop the flow.
Only the filter runs without Spring MVC; only the aspect fires for non-web method calls.
AOP works through a proxy, so a self-invocation inside the same bean silently skips the advice.

StackFeed

Filters vs Interceptors vs AOP — when each