fix: apply explicit @Schema(type) to the types set under OpenAPI 3.1

[forhadmethun]

Description

Under OpenAPI 3.1, an explicit @Schema(type = ...) was applied via the legacy scalar setType(), while the 3.1 serializer reads the types set. The set kept its default ("string"), so number / integer / boolean fields were rendered as string. This change populates the types set when openapi31 is enabled, mirroring the handling of the plural types() attribute directly below.

AnnotationsUtils.getSchemaFromAnnotation:

if (StringUtils.isNotBlank(schema.type())) {
    if (openapi31) {
        schemaObject.setTypes(new LinkedHashSet<>(Arrays.asList(schema.type())));
    } else {
        schemaObject.setType(schema.type());
    }
}

Before / After (OpenAPI 3.1) — given @Schema(type = "number") BigDecimal amount;:

• Before: amount: { type: "string" }
• After: amount: { type: "number" }

This is a bug fix. It is distinct from #5061 / #5062 (numeric example serialization); it concerns the property type and reproduces with no example present. Fields relying on type inference (no explicit type) were already correct.

Fixes: #5233

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

Screenshots / Additional Context

Added io.swagger.v3.core.resolving.v31.Ticket5233Test, asserting that explicit number / integer / boolean types land in the types set under OpenAPI 3.1, with inferred-type and enum properties as controls. The full swagger-core module test suite passes locally (721 tests, 0 failures).

[ewaostrowska]

Hi @forhadmethun, thank you for putting your time into this topic. As described in the #5233 we do not want to implement the bridging in between type and types for now. The behavior where all the scalar values for type default to string shall be fixed in the #5235.

[ewaostrowska]

After revisiting the topic a small update here:
The changes from this PR were fetched to the #5304 with slight modification of the logic to prioritize the implementation when it is set.

The bridging seems the simplest solution considering the addTypeWhenSiblingsAllowed needing to be fixed anyway since it is not only the OAS3.1 change - it also fires for the OAS 3.0 cases where siblings are allowed.

Thank you for the PR @forhadmethun and your investigation of the topic :)
Further explanation here.

[forhadmethun]

After revisiting the topic a small update here: The changes from this PR were fetched to the #5304 with slight modification of the logic to prioritize the implementation when it is set.

The bridging seems the simplest solution considering the addTypeWhenSiblingsAllowed needing to be fixed anyway since it is not only the OAS3.1 change - it also fires for the OAS 3.0 cases where siblings are allowed.

Thank you for the PR @forhadmethun and your investigation of the topic :) Further explanation here.

Thanks for pulling my changes into #5304 and for the extra work on the implementation logic! Glad I could help out. 😊