Add option `DefaultTyping.EVERYTHING` to support Kotlin data classes
See original GitHub issueMost usages of ObjectMapper.DefaultTyping
are NON_FINAL
which seems the wider scope available, which is real issue with Kotlin data classes which are final by design and can’t be open. As a consequence, usage in Spring Data Redis turn to be a very difficult journey (GenericJackson2JsonRedisSerializer
is very popular but not usable with Kotlin).
Is it possible to include a more Kotlin friendly enum value that would support final classes?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:9 (5 by maintainers)
Top Results From Across the Web
Kotlin : Data Classes - Medium
To add a parameterless constructor to your data class, you need to specify default values for each field. Therefore, your new data class...
Read more >FasterXML/jackson-databind - Gitter
I've configured activateDefaultTyping(objectMapper.polymorphicTypeValidator, DefaultTyping.EVERYTHING) on the objectMapper which generates fully typed JSON with ...
Read more >Axon query response not convertible using Jackson and Kotlin
Calling the defaultTyping() on the builder will set the appropriate setting on the ObjectMapper . You can find more information on the topic ......
Read more >1 Introduction - Micronaut Documentation
Note that in Java the annotations can be on the field or the getter and with Kotlin data classes the annotation should target...
Read more >jackson localdatetime not supported by default - You.com | The ...
LocalDateTime not supported by default: add Module ... kotlin data class ProductDto( val id: Long, val active: Boolean, val name: String, val description: ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hmmh. So after re-reading this again I finally understand the usage. So if serializing one of leaf types, nominal type is that
final
type but just because “real” base type can not be known without caller providing it.I guess that although there are other problems involved here (ideally base type should be indicated somehow), adding of new choice is probably not a bad idea.
I will add
DefaultTyping.EVERYTHING
.@isadounikau