#3314 fix has no effect if swagger-core resolved a schema before `ObjectMapperProvider` was created

未關閉
  • 哪裡不對？
#3,395 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 14 天內回覆

@Shubchynskyi 已經在處理了。

開始於 2026年10月29日。

  • #3396 來自 @Shubchynskyi —— 未關閉

評估

難度
4/5
預估耗時
3-5 天
新手友好度
45/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
java, spring-boot
領域
backend

研究方向

Start in ObjectMapperProvider, where the constructor registers SchemaTypeMixin on the shared Json31.mapper(), then follow SpringDocUtils.cloneViaJson and the fallback in AbstractRequestService.applyBeanValidatorAnnotations. Reproduce by creating a bean that calls AnnotationsUtils.resolveSchemaFromType before springdoc auto-configuration, then requesting /v3/api-docs for a constrained parameter. Done when cloning a JsonSchema with types no longer depends on mapper initialization order; run the relevant springdoc tests for OpenAPI 3.1 schema cloning.

由索引模型根據 Issue 內容生成。

描述

Describe the bug

With OpenAPI 3.1, Json Processing Exception occurred: Cannot construct instance of java.util.HashSet … from String value ('string') (through reference chain: io.swagger.v3.oas.models.media.JsonSchema["type"]) is still logged for every parameter with a validation constraint (@Min, @Pattern, @Size, …), although #3314 should have fixed this in 3.1.1. As a consequence, AbstractRequestService.applyBeanValidatorAnnotations falls back to modifying the original, possibly shared schema, which is the case #3270 meant to avoid.

Cause

ObjectMapperProvider registers SchemaTypeMixin on the JVM-wide Json31.mapper() in its constructor. Jackson only applies mixins to deserializers built afterwards, and caches those deserializers.

swagger-core uses the same mapper: ModelResolver copies property schemas via AnnotationsUtils.clone, which reads them back through ModelDeserializer, which in turn calls Json31.mapper().convertValue(node, JsonSchema.class) after removing type from the node. If that happens before ObjectMapperProvider is created, the cached JsonSchema deserializer lacks the TypeSetDeserializer. Every later SpringDocUtils.cloneViaJson fails, because it does not remove type first.

This happens in any application whose own configuration resolves a schema while it is being created. User configuration beans are instantiated before springdoc's auto-configuration. In our case it was an OperationCustomizer bean:

@Bean
public OperationCustomizer errorResponseSchemas(SpringDocConfigProperties properties) {
	Schema schema = AnnotationsUtils.resolveSchemaFromType(ApiResponseBody.class, null, null, properties.isOpenapi31());
	// …
}

To Reproduce

  • Spring Boot: 4.1.1
  • springdoc-openapi: 3.1.1 and 3.2.0
  • swagger-core: 2.2.55
  • springdoc.api-docs.version=OPENAPI_3_1 (the default)
  1. A bean in the application's own configuration that calls AnnotationsUtils.resolveSchemaFromType(SomeDto.class, null, null, true) for a class with properties.
  2. A controller method with a constrained parameter, e.g. @RequestParam @Min(1) Integer pageSize.
  3. Request /v3/api-docs: the warning is logged for that parameter.

At that point, objectMapperProvider.jsonMapper() is Json31.mapper() and findMixInClassFor(Schema.class) returns SchemaTypeMixin, yet SpringDocUtils.cloneViaJson of a JsonSchema with types = [integer] falls back to returning the original object. The same clone succeeds in a fresh JVM without the early bean.

Expected behavior

The schema is copied regardless of what used Json31.mapper() before springdoc was initialized.

Workaround

Inject ObjectMapperProvider into the bean that resolves schemas early, so that springdoc configures the mapper first. This makes the warnings disappear in our application.

Possible fix

Don't change the shared Json31.mapper(). Let ObjectMapperProvider configure its own instance instead, e.g. ObjectMapperFactory.createJson31() with SchemaTypeMixin, as createJson already does for the standalone mappers. Alternatively, swagger-core could make the 3.1 type property readable back in the form it writes it (swagger-api/swagger-core#5264), which would make the mixin unnecessary.

主要語言
Java
星號
3.7k
分支
605
平均合併
12 天 22 小時
30 天內合併 PR
10

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

springdoc/springdoc-openapi 的其他 Issue

查看 springdoc/springdoc-openapi 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。