#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 摘要。