skip to content

What is WebFluxConfigurer and how do you use it to customize Spring WebFlux?

level: juniorimportance: must knowfreq 55%

answer

  1. Callback interface, all default no-ops
  2. Override only what you need
  3. Boot: implement WITHOUT @EnableWebFlux
  4. Composite fans out to all beans
  5. addCors / codecs / formatters / argresolvers / content-negotiation

basics

~10 s

WebFluxConfigurer is an interface with optional callback methods. You implement it on a @Configuration class to customize the reactive web setup — CORS, formatters, argument resolvers, codecs, content negotiation — without replacing Spring's defaults.

solid answer

~40 s

WebFluxConfigurer is a callback interface for tuning Spring's reactive web infrastructure. You declare a @Configuration bean that implements it and override just the callbacks you need — addCorsMappings, addFormatters, addArgumentResolvers, configureHttpMessageCodecs, configureContentTypeResolver, and so on. Every method is a Java default (no-op), so you override only what you want; the rest keep Spring's defaults. Spring detects all WebFluxConfigurer beans and applies each in turn, so multiple configurers compose. Crucially, in Spring Boot you implement WebFluxConfigurer WITHOUT adding @EnableWebFlux — that keeps Boot's WebFlux auto-configuration active and layers your tweaks on top. Adding @EnableWebFlux would switch off auto-config and hand you full control (and full responsibility). WebFluxConfigurer is the additive, low-risk extension point.

code

java · 16 lines
java
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.config.CorsRegistry;
import org.springframework.web.reactive.config.WebFluxConfigurer;

// In Spring Boot: NO @EnableWebFlux -> auto-config stays on, this only adds tweaks
@Configuration
public class WebConfig implements WebFluxConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://app.example.com")
                .allowedMethods("GET", "POST");
    }
    // every other callback keeps Spring's default behaviour
}

go deeper

for a junior

Know it's an interface you implement on a @Configuration class to tweak WebFlux, with methods like addCorsMappings.

for a middle

Know callbacks are default no-ops, that multiple configurers compose, and the Boot rule: implement it without @EnableWebFlux.

for a senior

Explain the WebFluxConfigurerComposite fan-out, additive vs replacing callbacks, and when to escalate to WebFluxConfigurationSupport.

for a principal

Reason about ordering, which callbacks are single-value vs additive, and the trade-off between additive configurers and taking over the whole reactive config.

## What it is `WebFluxConfigurer` is an interface in `org.springframework.web.reactive.config` that Spring calls back into while it builds the reactive web machinery. It is the WebFlux analogue of `WebMvcConfigurer` in Spring MVC. Every method on the interface is a Java `default` method with an empty body, so implementing the interface forces you to write nothing — you override only the callbacks relevant to your customization and inherit no-ops for the rest. ## How Spring finds and uses it The reactive configuration class (`WebFluxConfigurationSupport`, imported via `@EnableWebFlux` or activated by Boot's auto-config) autowires **all** beans of type `WebFluxConfigurer` from the context into a `WebFluxConfigurerComposite`. During startup it invokes each callback on the composite, which fans the call out to every registered configurer. Consequences: - You can have **many** `WebFluxConfigurer` beans and they all contribute (e.g. one for CORS, one for codecs). Order is generally the bean order; most callbacks are additive registries so order rarely matters. - Because callbacks run **at bean-definition/startup time**, you cannot 'reconfigure' WebFlux at runtime through this interface — it shapes the singletons once. ## The key callbacks (this leaf's scope) - `addCorsMappings(CorsRegistry)` — global CORS rules. - `configureHttpMessageCodecs(ServerCodecConfigurer)` — register/customize the codecs used to read request bodies and write responses. - `addFormatters(FormatterRegistry)` — register custom `Converter`/`Formatter` for type conversion (path vars, query params, form fields). - `addArgumentResolvers(ArgumentResolverConfigurer)` — add **custom** `HandlerMethodArgumentResolver`s for controller parameters. - `configureContentTypeResolver(RequestedContentTypeResolverBuilder)` — how the requested media type is determined (content negotiation). - Others outside this leaf's focus: `addResourceHandlers`, `configureViewResolvers`, `configurePathMatching`, `getValidator`, `getMessageCodesResolver`, `configureBlockingExecution`. ## When to use - Use `WebFluxConfigurer` for **additive** tweaks that should coexist with defaults. - In **Boot**: implement the interface and do NOT annotate with `@EnableWebFlux`, so auto-config stays on. - In **plain Spring** (no Boot): you must add `@EnableWebFlux` somewhere to bootstrap the infrastructure; your configurer then customizes it. ## Gotchas - Implementing `WebFluxConfigurer` is a no-op unless the reactive infrastructure is actually active (Boot auto-config or `@EnableWebFlux`). - Returning a value where the callback expects registration (e.g. `getValidator`) replaces a default; the additive `add*`/`configure*` methods do not. - This is server-side WebFlux (`spring-webflux` on a reactive `WebHandler` stack); it has nothing to do with annotated MVC controllers on the Servlet stack.

  • Can you register more than one WebFluxConfigurer, and what happens if two configure the same thing?
    Yes — Spring collects all WebFluxConfigurer beans into a WebFluxConfigurerComposite and invokes every callback on each. For additive registries (CORS, formatters, argument resolvers) all contributions accumulate. For single-value callbacks like getValidator, having two non-null returns is ambiguous and Spring throws, so only one configurer should provide those.
  • Why is WebFluxConfigurer preferred over extending WebFluxConfigurationSupport?
    WebFluxConfigurer is additive and composes with defaults and with other configurers. Extending WebFluxConfigurationSupport (or using @EnableWebFlux which imports it) takes over the whole configuration and, in Boot, disables auto-configuration — more control but you own every default from then on.

saying these in an interview costs you the question

  • Thinking you must add @EnableWebFlux in Spring Boot to use WebFluxConfigurer (that actually disables auto-config)
  • Believing overriding one callback replaces all defaults (only that one callback is affected)
  • Confusing WebFluxConfigurer with WebMvcConfigurer / the Servlet stack

context

resolving links…