skip to content

When would you extend WebFluxConfigurationSupport (or use DelegatingWebFluxConfiguration) instead of implementing WebFluxConfigurer, and what are the trade-offs?

level: principalimportance: nice to knowfreq 22%

answer

  1. Configurer = additive; Support = replace/override @Bean methods
  2. @EnableWebFlux imports DelegatingWebFluxConfiguration
  3. Delegating = Support + wires configurer composite
  4. Extending disables Boot auto-config; don't also @EnableWebFlux
  5. Bare Support won't apply configurer beans

basics

~20 s

Implement WebFluxConfigurer for additive tweaks that keep defaults. Extend WebFluxConfigurationSupport only when you must replace or fully control the infrastructure beans by overriding its @Bean methods — at the cost of disabling Boot auto-config and owning every default yourself.

solid answer

~50 s

WebFluxConfigurer is the additive, recommended extension point: callbacks layer on top of the default beans and compose with other configurers. WebFluxConfigurationSupport is the base @Configuration that actually declares those beans (DispatcherHandler, handler mappings/adapters, ServerCodecConfigurer, content-type resolver, etc.); DelegatingWebFluxConfiguration extends it and wires in your WebFluxConfigurer beans — that's exactly what @EnableWebFlux imports. You extend WebFluxConfigurationSupport directly only when a configurer callback isn't enough and you must override a bean-definition method itself — e.g. replace the RequestMappingHandlerMapping with a subclass, change how the RequestMappingHandlerAdapter is built, or customize infrastructure with no callback. The trade-offs: it puts a WebFluxConfigurationSupport bean in the context, so in Boot the WebFlux auto-configuration backs off and you inherit responsibility for defaults; and you can't combine it with @EnableWebFlux (that would import a second support instance). Reach for it rarely, as a last resort for deep infrastructure control.

code

java · 14 lines
java
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.config.DelegatingWebFluxConfiguration;
import org.springframework.web.reactive.result.method.annotation.RequestMappingHandlerMapping;

// Deep control: subclass an infrastructure bean. Extend Delegating (not bare Support)
// so WebFluxConfigurer beans are still applied. NOTE: do not also add @EnableWebFlux.
@Configuration
public class CustomWebFluxConfig extends DelegatingWebFluxConfiguration {

    @Override
    protected RequestMappingHandlerMapping createRequestMappingHandlerMapping() {
        return new MyCustomRequestMappingHandlerMapping(); // change mapping behaviour
    }
}

go deeper

for a junior

Know that implementing WebFluxConfigurer is the normal way; extending the support class is advanced.

for a middle

Know extending WebFluxConfigurationSupport replaces beans and disables Boot auto-config.

for a senior

Explain the Delegating-vs-bare-Support distinction and that only Delegating wires configurer beans.

for a principal

Choose the right control level per requirement, reason about upgrade fragility from overriding framework @Bean methods, and avoid conflicting entry points.

## The three levels of control 1. **WebFluxConfigurer (additive, preferred).** Implement the interface, override callbacks. Defaults stay; multiple configurers compose. In Boot, works without `@EnableWebFlux`, preserving auto-config. 2. **@EnableWebFlux (take over via import).** Imports `DelegatingWebFluxConfiguration`. Registers all the default infrastructure beans and delegates customization to your `WebFluxConfigurer` beans. In Boot this disables `WebFluxAutoConfiguration` (its `@ConditionalOnMissingBean(WebFluxConfigurationSupport.class)` guard fails). 3. **Extend WebFluxConfigurationSupport (deep control).** Subclass the base config class and override its `@Bean` factory methods. This is the most invasive: you can change how the framework's own beans are constructed, not merely feed them customization callbacks. ## What WebFluxConfigurationSupport provides It is the class that declares the reactive web beans as `@Bean` methods, e.g.: - `webHandler()` / `DispatcherHandler` - `requestMappingHandlerMapping(...)`, `requestMappingHandlerAdapter(...)` - `routerFunctionMapping(...)` - `serverCodecConfigurer()` - `webFluxContentTypeResolver()` (the `RequestedContentTypeResolver`) - `webFluxConversionService()`, `webFluxValidator()`, exception handlers, etc. Many of these methods are designed to be overridden (they call protected template methods). `DelegatingWebFluxConfiguration` is simply `WebFluxConfigurationSupport` plus autowiring of a `WebFluxConfigurerComposite`, so the configurer callbacks are honoured. ## When extending is justified - You need a **subclass** of an infrastructure bean, e.g. a custom `RequestMappingHandlerMapping` that changes mapping detection, or a custom `HandlerAdapter`. - You must alter bean **construction** or ordering that no `WebFluxConfigurer` callback exposes. - You are building framework-level tooling / a custom platform on top of WebFlux. If a callback exists for what you need (CORS, codecs, formatters, argument resolvers, content negotiation, resource handlers, path matching, validator), **use the callback** — extending is unnecessary and riskier. ## Trade-offs / gotchas - **Auto-config off (Boot).** Because your subclass IS a `WebFluxConfigurationSupport`, Boot's `WebFluxAutoConfiguration` backs off; you lose Boot-curated defaults (codec limits, static resources, Jackson wiring) unless you reproduce them by overriding the right methods. - **Do not also add @EnableWebFlux.** That imports `DelegatingWebFluxConfiguration`, giving two support instances — redundant/conflicting. Pick one path. - **You still honour WebFluxConfigurer?** Only if you extend `DelegatingWebFluxConfiguration` (which wires configurers) — extending the bare `WebFluxConfigurationSupport` means configurer beans are NOT applied unless you add that plumbing. - **Upgrade fragility.** Overriding framework `@Bean` methods couples you to internal construction details that can change across Spring versions. ## Decision guide - Additive change -> `WebFluxConfigurer` (no `@EnableWebFlux` in Boot). - Replace whole default set but still via callbacks -> `@EnableWebFlux`. - Override a specific infrastructure bean's construction -> extend `WebFluxConfigurationSupport` (or `DelegatingWebFluxConfiguration` to keep configurer support), accept auto-config loss.

  • If you extend the bare WebFluxConfigurationSupport, are your WebFluxConfigurer beans still applied?
    No. Bare WebFluxConfigurationSupport does not autowire the configurer composite. Only DelegatingWebFluxConfiguration (what @EnableWebFlux imports) wires WebFluxConfigurer beans in. Extend Delegating instead if you want both custom bean overrides and configurer callbacks.
  • Why can't you combine @EnableWebFlux with extending WebFluxConfigurationSupport?
    @EnableWebFlux imports DelegatingWebFluxConfiguration, itself a WebFluxConfigurationSupport. Adding your own subclass means two support configurations defining the same infrastructure beans — redundant and conflicting. Choose exactly one entry point.

saying these in an interview costs you the question

  • Reaching for WebFluxConfigurationSupport when a WebFluxConfigurer callback already covers the need
  • Extending bare WebFluxConfigurationSupport and expecting WebFluxConfigurer beans to still apply
  • Combining @EnableWebFlux with a WebFluxConfigurationSupport subclass

context

resolving links…