Enable usage of custom serializers/deserializers

[AlexandrSokolov]

Can you please again consider adding this functionality. I've seen the issue, which is closed now.

The problem with the solution you offer, via @TypeHint and @DocumentationExample or with Jackson annotation like @JsonSerialize is that it forces to specify them per each attribute/property/dto object.

The beauty of custom serializers/deserializers - is an ability to register global ones per type. For instance per java.util.Date, or per ZonedDateTime. Like:

public class ZonedDateTimeSerializer extends JsonSerializer<ZonedDateTime> {

  @Override
  public void serialize(ZonedDateTime value, JsonGenerator jgen, SerializerProvider provider) throws IOException {
    ...
  }
}
... //registration:
module.addSerializer(ZonedDateTime.class, new ZonedDateTimeSerializer());

After that a developer should not think about this aspect. It dramatically simplifies development.

You might find in the source code all such JsonSerializer and JsonDeserializer, create some custom value of ZonedDateTime for instance and then get a formatted value from JsonGenerator.

Or you might add a configuration ability, to add a mapping between certain java type and a custom serializer/deserializer.

Or, in the worst case, but the simplest solution, you might provide a configuration to specify datetime format. And list of java types that should be affected. In the generated examples, you might use it to show the expected string value.

Probably it is enough to handle only serializers, cause it gives a string representation which is the same in the request and response, mostly.

I am talking now only about docs generation. For clients generation it also a challenge to implement it. These serializers/deserializers must be registered.

[stoicflame]

Acknowledged.

You might find in the source code all such JsonSerializer and JsonDeserializer, create some custom value of ZonedDateTime for instance and then get a formatted value from JsonGenerator.

This option is not viable because Enunciate works with the pre-compiled source code and not with the post-compiled bytecode. There's no generic way to "create some custom value" of an object and "get a formatted value from JsonGenerator". In the example above, Enunciate can't assume that ZonedDateTimeSerializer is even compiled at the time that Enunciate runs.

Or you might add a configuration ability, to add a mapping between certain java type and a custom serializer/deserializer.

This functionality could be added if needed.

Or, in the worst case, but the simplest solution, you might provide a configuration to specify datetime format. And list of java types that should be affected. In the generated examples, you might use it to show the expected string value.

This is already implemented, e.g.:

<enunciate>
  <modules>
    <jackson dateFormat="date_time"/>

Also see the changes requested at #1026 that have already been included in version 2.13.1.

For now, I'll keep this issue open to accommodate the suggested configuration enhancement for custom (de)serializers.

[AlexandrSokolov]

@stoicflame , thank you for your feedback. There is one important issue with default types. There is no a common default value. It depends on company, country, personal opinion. Some people prefer to get timestamp, some in the local date-time format, some with a zone number.

My proposal with serializers/deserializers is not a good one. I agree. What can be done - to provide their analog via jackson configuration. Please consider the following example:

    <jackson
      dateFormat="string"
      disabled="false">
      <dataTypeMappings>
        <java.util.Date>2020-05-27 24:35:75</java.util.Date>
        <java.time.ZonedDateTime>2020-05-27'T'124:35:75'Z'</java.time.ZonedDateTime>
        <java.math.BigDecimal>12345.78</java.math.BigDecimal>
      </dataTypeMappings>
    </jackson>

It can be shared and used both for request/responses (serialization/deserialization). It is very clear. It is actually an alternative way to specify formats for certain types globally.

[AlexandrSokolov]

Actually you can close the issue. You have already provided a solution via "examples" in the configuration file. It plays the same role I've described above. And it is really awesome. I could get rid of all annotations, extra dependency, left only plugin and global configuration.