Build 1 publisher2 min readPublished September 19, 2026 at 3:56 AM PDT

A filter rejects a request before Spring picks the controller that would have handled it

Spring gives three places to run code around a request, and each one sees a different amount. A dev.to walkthrough puts filters outside the DispatcherServlet, interceptors inside it, and aspects around any bean method.

The Engineer · Build desk

What happened

A dev.to walkthrough places servlet filters outermost on raw HTTP, handler interceptors inside the DispatcherServlet, and AOP aspects around any bean method, and argues the ordering decides what each can see.
A Filter comes from the Servlet spec, not Spring, and wraps the request before Spring runs, seeing only the raw HttpServletRequest and HttpServletResponse.
Inside a filter, chain.doFilter divides inbound from outbound work, and skipping the call ends the request there, which the post illustrates by rejecting a missing API key.
Returning false from preHandle stops the request and the controller never runs; the post's example sets status 401 when the X-User header is missing.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

decision Auth that depends on an annotation on the controller method can only go in the interceptor, because only the interceptor holds the handler object; the same rule in a filter has to be reconstructed from the URL string.
constraint Metrics or request logging registered as an interceptor will undercount traffic, since requests for static files and error paths never reach a handler and so never reach the interceptor.
capability Because an aspect wraps bean methods and fires for non-web calls, audit or retry logic that also has to cover a scheduler or queue listener can live in one place instead of two.

A filter holds both the request and the response, so it can wrap or replace the response body ^[8]. The dev.to post puts compression, CORS headers and request-body caching in that layer for that reason ^[17]. Spring Security is itself built as one big filter ^[9].

Both web layers can stop a request, and they stop it at different points. Skip `chain.doFilter` and the request ends inside the filter, before any Spring code runs; the post's example is rejecting a missing API key ^[7]. Return `false` from `preHandle` and the request also ends, but the DispatcherServlet has already read the URL and chosen the handler ^[3]^[10]^[11]. The interceptor rejection has already done handler resolution by then; the filter rejection has not ^[1].

The interceptor gets more information for that extra work. `preHandle` receives the handler object, and the post notes you can read the target method's annotations off it ^[13]. A filter never knows which controller will run ^[5]. So per-route auth keyed on an annotation is interceptor work, and so is request logging that names the method ^[18]. Registration is by URL pattern: `registry.addInterceptor(new AuthInterceptor()).addPathPatterns("/api/**")` in the post's `WebConfig` ^[12].

Interceptors also get three hooks around the controller call ^[14], one of which lets you touch the model before the view renders ^[18]. Only code running inside the DispatcherServlet can reach the model there.

Aspects sit deeper again. An aspect wraps any bean method and fires for non-web calls too ^[15]. A concern that must also apply when a scheduler or a queue listener calls the same service is not a web concern at all, and the aspect is the only one of the three layers that sees that call. The post stops there on aspects.

The ordering generalises the way the post states it: moving inward, each layer sees more Spring detail and less raw HTTP ^[16]. It holds where a servlet container such as Tomcat or Jetty is handing Spring a raw `HttpServletRequest` ^[2], and it describes only the requests that reach the DispatcherServlet, which is the component that maps a URL to a controller method and turns the return value into a response ^[3].

What to watch

Where a custom filter lands relative to Spring Security's own filter chain, since both occupy the same outermost layer.
Whether the ordering in the post's diagram holds outside a servlet stack; it assumes Tomcat or Jetty hands Spring a raw HttpServletRequest.
How much URL matching and handler selection a preHandle rejection actually pays for in a running app, which the post does not measure.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
Filters, interceptors, and aspects are three places to run code around a request, at three different depths of the stack: filters outermost, handler interceptors inside the DispatcherServlet, and AOP aspects around bean methods.
ReportedSupportedSource: dev.to post 'Filters vs Interceptors vs AOP - when each'View cited source
[2]
The servlet container (Tomcat, Jetty) is the web server that speaks HTTP and hands the app a raw HttpServletRequest.
ReportedSupportedView cited source
[3]
DispatcherServlet is 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.
ReportedSupportedView cited source
[4]
A Filter is part of the Servlet spec, plain Jakarta/Java EE and not Spring, and it wraps the request before Spring even runs.
ReportedSupportedView cited source
[5]
A filter sees the raw HttpServletRequest and HttpServletResponse, and nothing about which controller will run.
ReportedSupportedView cited source
[6]
chain.doFilter(...) is the pivot in a filter: everything before it runs on the way in, everything after it runs on the way out.
ReportedSupportedView cited source
[7]
If you never call chain.doFilter, the request stops in the filter; that is how a filter blocks a request entirely, for example rejecting a missing API key before any Spring code runs.
ReportedSupportedView cited source
[8]
A filter holds both the request and the response, so it can wrap or replace the response body.
ReportedSupportedView cited source
[9]
Spring Security itself is built as one big filter.
ReportedSupportedView cited source
[10]
A HandlerInterceptor runs inside the DispatcherServlet, after Spring has already decided which handler will serve the request, so it knows the handler.
ReportedSupportedView cited source
[11]
Returning false from preHandle stops the request and the controller never runs; the post's AuthInterceptor sets status 401 when the X-User header is absent.
ReportedSupportedView cited source
[12]
An interceptor is registered against URL patterns in a WebMvcConfigurer: registry.addInterceptor(new AuthInterceptor()).addPathPatterns("/api/**").
ReportedSupportedView cited source
[13]
The handler argument passed to preHandle lets you read the target method's annotations.
ReportedSupportedView cited source
[14]
A HandlerInterceptor gives three hooks around the controller call.
ReportedSupportedView cited source
[15]
An AOP aspect sits deepest, wraps any bean method, and fires for non-web calls too.
ReportedSupportedView cited source
[16]
As you move inward through the three layers, each one sees more Spring detail and less raw HTTP.
ReportedSupportedView cited source
[17]
Filters are good at work that must happen for every HTTP request, controller-bound or not, including static files and error paths; at reading or modifying the raw request and response (compression, CORS headers, caching the request body); and at security gates that should run before Spring.
ReportedSupportedView cited source
[18]
Interceptors are good at web concerns that need to know the controller or endpoint, such as per-route auth and request logging that names the method, and at anything tied to the MVC lifecycle, like touching the model before the view renders.
ReportedSupportedView cited source
[19]
A cross-cutting concern is a job that applies to many requests or many methods, cutting across normal code instead of belonging to one spot; examples given are logging, timing, auth checks, adding headers and collecting metrics.
ReportedSupportedView cited source
[d1]
A rejection issued in a filter happens before Spring reads the URL and selects a handler, while a rejection issued in preHandle happens after that work has been done, so the same rejection costs handler resolution in the interceptor case and not in the filter case.
DerivedSupported1 source— sign in to open
[d2]
Because an interceptor only runs once a handler has been selected, requests that no controller serves, such as static files and error paths, are visible to a filter but not to an interceptor.
DerivedSupported1 source— sign in to open

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 19, 2026
Filters vs Interceptors vs AOP — when each

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

dev.to answers "which of the three?" by depth. The filter sees raw HTTP and nothing about which controller will run. Once Spring has chosen the handler, an interceptor receives that handler as an argument and can read the target method's annotations. Deeper still, an aspect wraps any bean method, including calls that never arrived over HTTP. Each layer comes with code you can paste: TimingFilter, AuthInterceptor, LoggingAspect. The shape repeats across all three, since chain.doFilter, a true return from preHandle, and pjp.proceed() all mark the same handoff to the real work. The post leaves out ordering when two filters both want to run first, and it does not mention that a bean calling its own method bypasses its own aspect.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence58

0100

Checkable code, one account

Nearly every statement here is printed as code a reader can run: the filter that skips chain.doFilter, the preHandle that sets 401 and returns false, the pointcut naming the service package. That puts the mechanics beyond argument. It also stops there. No Spring documentation or second write-up in our coverage confirms the layer ordering, and the text we received breaks off partway through the list of jobs aspects are good at.

AdoptionInsufficient

No usage to measure

Nothing here is a release or a deployment. The post teaches Spring APIs that already exist and does not report versions, rollouts, or how often teams pick one layer over another, so there is no adoption signal to score.

Hype gap0

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

build
The proxy in your call path decides whether @Transactional does anything at all
1 publisher
build
Spring's @Scheduled swallows the exception and reports success to the scheduler
1 publisher
build
In Spring, the hook you need is decided by the clock, not by the name
1 publisher
build
A green @DataJpaTest can prove only that Hibernate handed back the same object
1 publisher

A filter rejects a request before Spring picks the controller that would have handled it

What happened

Why it matters

What to watch

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Sources

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Reality

Related stories

Sources