fix: treat number example as number and not string

[Mattias-Sehlstedt]

Pull Request

Thank you for contributing to swagger-core!

Please fill out the following information to help us review your PR efficiently.

---

Description

Restores part of the schema example construction that was lost with PR #5046 and the change of this line.

The behavior that has been reintroduced is that an example for a number schema (number/integer) retains the old behavior of using the JsonNode as the example value, rather than using its String-representation. This will in turn lead to the example being a number in the specification.

This is of importance since the example value should align with the type defined in the schema.

Fixes: #5061

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

[Mattias-Sehlstedt]

Edit: I have added test Issue5061Test to showcase that the issue presented below is managed by the fact that the field type is introspected and passed on to the AnnotationUtils as existingSchema. This in turn leads to the AnnotationUtils having the possibility to derive whether example="5" should become the number representation 5 or the string representation "5".

---

As raised in a comment on the issue this does not entirely corrects for the issue. This fix only corrects the behavior when the user explicitly states a type in the Schema annotation. If the type is not explicitly defined then it will for example still incorrectly generate an example for

private record ExampleDto(
  @Schema(example = "10.00") BigDecimal value) {
})

"ExampleDto": {
  "type": "object",
    "properties": {
      "exampleDec": {
        "type": "number",
        "example": "10.00"  <--
      }
    }
  }

The issue is that the example calculator currently does not have access to the field type. So if it sees "5" as an example, it can not properly derive whether it is a number and should be 5, or if it is a string and should be "5".