[REQ][Kotlin][Jackson] Add support to enable/disable Jackson's features

[hpedrorodrigues]

Is your feature request related to a problem? Please describe.

I'm using the OpenAPI generator to generate a Kotlin client with Jackson as a serialization library, but I cannot customize the object mapper with the generator. If I want to customize it, I need to import the Serializer object and customize it using the property jacksonObjectMapper.

Describe the solution you'd like

I'd like to enable/disable Jackson's features using the generator's config file.

Describe alternatives you've considered

I changed the object mapper directly, accessing Serializer#jacksonObjectMapper.

Additional context

Also, we have some defaults for Java that we're not applying for Kotlin.
Is there a specific reason we're not using the same defaults?

Reference:

• Java | ApiClient
• Kotlin | Serializer#jacksonObjectMapper

[iaroslav42]

+1 for this issue.
Currently it's not possible to make it generate Jackson ObjectMapper with FAIL_ON_UNKNOWN_PROPERTIES = false like it's done in Java | Api Client. That makes this generator (when using Jackson) unusable for many (most?) use cases, because the client will be breaking on e.g. adding new fields to API responses (which technically is not a breaking API change).

Is there a specific reason we're not using the same defaults?

Also wondering about that. I guess changing the defaults now would be a breaking change, but to me it feels like the current defaults are kinda wrong (i.e. failing on unknown JSON properties) and inconsistent with Java client generator 🤔

[jasenkoh]

Is there any update on this issue?

[AlessandroBagnoli]

+1 for this issue. Currently it's not possible to make it generate Jackson ObjectMapper with FAIL_ON_UNKNOWN_PROPERTIES = false like it's done in Java | Api Client. That makes this generator (when using Jackson) unusable for many (most?) use cases, because the client will be breaking on e.g. adding new fields to API responses (which technically is not a breaking API change).

Is there a specific reason we're not using the same defaults?

Also wondering about that. I guess changing the defaults now would be a breaking change, but to me it feels like the current defaults are kinda wrong (i.e. failing on unknown JSON properties) and inconsistent with Java client generator 🤔

the breaking on adding new fields to API responses can be avoided with this option in your config.yaml:
additionalModelTypeAnnotations: "@com.fasterxml.jackson.annotation.JsonIgnoreProperties(ignoreUnknown = true)"
However, the problem persists whenever new enum values are added to an API.
Would be great to have the enumUnknownDefaultCase option available for the Java generator