Skip to content

SpringDocWebMvcConfiguration relies on unspecified autoconfiguration ordering. Fixes #3313 - #3316

Open
kdelay wants to merge 1 commit into
springdoc:mainfrom
kdelay:fix/issue-3313-autoconfigure-after
Open

SpringDocWebMvcConfiguration relies on unspecified autoconfiguration ordering. Fixes #3313#3316
kdelay wants to merge 1 commit into
springdoc:mainfrom
kdelay:fix/issue-3313-autoconfigure-after

Conversation

@kdelay

@kdelay kdelay commented Aug 8, 2026

Copy link
Copy Markdown

Fixes #3313

Problem

SpringDocWebMvcConfiguration is gated on @ConditionalOnBean(SpringDocConfiguration.class) but never declares that it has to be evaluated after SpringDocConfiguration. The condition matches today only because org.springdoc.core.configuration.SpringDocConfiguration happens to sort before org.springdoc.webmvc.core.configuration.SpringDocWebMvcConfiguration in Spring Boot's auto-configuration sort.

Any ordinary third-party auto-configuration whose class name sorts earlier and which orders itself around a springdoc auto-configuration changes the topological sort. SpringDocWebMvcConfiguration is then evaluated before SpringDocConfiguration is registered, the @ConditionalOnBean does not match, and OpenApiWebMvcResource disappears with no error.

The same undeclared assumption exists in every other auto-configuration entry that is gated on SpringDocConfiguration, so this is not specific to Web MVC. The -mcp starters already declare it (@AutoConfiguration(after = SpringDocConfiguration.class)); the older @Configuration-based ones do not.

Change

Added @AutoConfigureAfter(SpringDocConfiguration.class) to the 22 auto-configuration entries that carry @ConditionalOnBean(SpringDocConfiguration.class), across the common, webmvc/webflux api, ui and scalar starters. No behaviour other than registration order is touched.

Added SpringDocAutoConfigurationOrderTest, which reads every AutoConfiguration.imports entry on the classpath with ASM (no class loading, since several entries reference optional types) and asserts that anything gated on SpringDocConfiguration also declares the order. On the unmodified tree it reports every affected class; it is what surfaced SpringDocKotlinConfiguration, which is easy to miss because it is a .kt file.

Verification

Reproduced with the reporter's project from #3313 (Spring Boot 4.1.0 + Jetty, the two springdoc starters, and one third-party @AutoConfiguration(after = SpringDocWebMvcConfiguration.class) contributing no beans), on JDK 17 / macOS:

  • springdoc 3.1.0: OpenApiMissingWithThirdPartyAutoConfigTest fails, OpenApiWebMvcResource is absent. The baseline test that excludes the third-party auto-configuration passes.
  • this branch installed as 3.1.1-SNAPSHOT: both tests pass, Tests run: 2, Failures: 0.

mvn install on the full reactor passes on this branch, with two exceptions that also fail on unmodified main here (checked out main and re-ran both): test.org.springdoc.api.v31.app193.SpringDocApp193Test in the webmvc-api module (components.schemas.Animal Expected: type but none found) and test.org.springdoc.api.v31.app3.SpringDocApp3Test in the kotlin-webmvc-tests module (components.schemas.Foo.properties.bar Unexpected: uniqueItems). Every other module is green, 647 tests in webmvc-api included.

Note for reviewers: this cannot be reproduced through ApplicationContextRunner with AutoConfigurations.of(...). I tried that first and the test passed with and without the fix, because the ordering constraint only takes effect through the real AutoConfiguration.imports mechanism. That is why the added test asserts the declared order instead of booting a context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SpringDocWebMvcConfiguration relies on unspecified autoconfiguration ordering

1 participant