Expansion of properties doesn't seem to work for numeric fields

[rdesgroppes]

Expansion of properties doesn't seem to work for schema examples set on numeric fields.

Steps to Reproduce

1. Have a project with a custom openapi.properties file (as per https://micronaut-projects.github.io/micronaut-openapi/latest/guide/index.html#propertiesFileConfiguration)
2. Add a property micronaut.openapi.expand.example.version=42 to it
3. Get the property expanded in the example of a String field and in the example of a long one:

   @Schema(example = "${example.version}")
   public String getVersionString() {
     return "foo";
   }
   @Schema(example = "${example.version}")
   public long getVersionLong() {
     return 0;
   }

4. generate the OpenAPI spec

Expected Behaviour

The property gets expanded (to 42) in both cases.

Actual Behaviour

The example gets only expanded for the String field, and turns out to be stripped out for the long field.

Environment Information

micronaut 2.5.8 (micronaut-openapi 2.4.0).

[ilopmar]

This is not as simple as it seemed at the beginning so I'm writing here what I've discovered and tried just to remember when I get back to this issue.

Issue

What happens is that in line 1010 we use jackson to update the schemaToBind, which is the @Schema we are processing for the current property, with the values from schemaJson (that contains something like {"example":"${example.version}"}:

micronaut-openapi/openapi/src/main/java/io/micronaut/openapi/visitor/AbstractOpenApiVisitor.java

Lines 1007 to 1013 in 1c8b2e1

	private Schema doBindSchemaAnnotationValue(VisitorContext context, Element element, Schema schemaToBind,
	JsonNode schemaJson, String defaultValue, String... allowableValues) {
	try {
	schemaToBind = jsonMapper.readerForUpdating(schemaToBind).readValue(schemaJson);
	if (StringUtils.isNotEmpty(defaultValue)) {
	schemaToBind.setDefault(defaultValue);
	}

This triggers the call of setExample method in Swagger jar:

public void setExample(Object example) {
    this.example = cast(example);
    if (!(example != null && this.example == null)) {
        exampleSetFlag = true;
    }
}

And in that method the cast(example) does a cast of the value to the appropriate type of schema. This works when defining the property as String because the casting of ${example.version} to String is successful and it returns the same String value (${example.version}).

When doing the same when processing the property (or the getter in this example) defined as Long, the cast(example) returns null because it is not possible to cast that String to a valid Long value, so the example is defined as null in the Schema (IntegerSchema in this case).

At the end of the of the generation of the OpenAPI spec file, we try to resolve the placeholders to their final values here:

micronaut-openapi/openapi/src/main/java/io/micronaut/openapi/visitor/OpenApiApplicationVisitor.java

Line 500 in 1c8b2e1

openAPI = resolvePropertyPlaceHolders(openAPI, visitorContext);

So, as mentioned, only the property defined as String has the example property set to ${example.version} and that is replaced with it's final value (42 in the example). The Long property has example set to null so nothing is changed.

Fix tried

I've tried do the binding with:

schemaToBind = jsonMapper.readerForUpdating(schemaToBind).readValue(schemaJson, Schema.class);

So a new Schema is created when doing the binding. This returns an ObjectSchema instead of the right StringSchema, IntegerSchema,... so I've even tried to manually modify the type and format doing:

schemaToBind.setType(originalSchema.getType());
schemaToBind.setFormat(originalSchema.getFormat());

But it feels really dirty and even if it works for this use case it breaks a bunch of tests.

Fix

What I think we need to do to resolve this issue is resolve the placeholders before doing the binding so we would be able to bind 42 to a Long value. I see a couple of problems with this approach:

• We need to do a big refactor because the properties are resolved at one place at the end of the processing. We need to initialize the properties at the beginning and be able to do lookups to resolve the values.
• I'm not sure if resolving the placeholders only during this binding (an another one for Arrays) would be enough or maybe we need to do it in more places.
• Another option could be to do the binding in those two places and also at the end of the processing (as we are currently doing).