When running spring webflux app with kotlinx.seria...
# spring
r
When running spring webflux app with kotlinx.serialization enabled I get
500 Internal Server Error
when there is a problem with deserialization (e.g. missing key in the request data). When using jackson serialization with the same data the error is
400 Bad Request
. Can I somehow configure the returned error for kotlinx.serialization?
h
kotlinx.serialization only throws an Exception – it's the Spring framework turning that into an HTTP error code returned. You have to configure that mapping in Spring, it's probably preconfigured for Jackson only. This huge blogpost gives a good overview, you'll probably want to write a
@ControllerAdvice
for the exceptions thrown by kotlinx.serialization.
🙏 1
👍 1
t
since I was curious about kotlin serialization, can you summarize why would you switch from jackson to kotlin serialization in spring? jackson is quite easy, integrate and fast (due to caching magic afaik), while with kotlin serialization you need be a lot more explicit (which I guess makes the code more readable but a lot harder to write). very limited experience with kotlin serialization here though
e
Not OP but here's my reasons. Jackson is slower and imo outright dangerous to use since it can deserialize null values into non nullable properties through reflection.
t
you sure about the
null
point? I switched to nullable properties a while back with javax validation annotation (most often then not we anyway have other constraints, like numbers must be positive, or string non blanks etc), but I remember getting some binding exception when sending
null
to non null fields. I guess kotlin serialization would throw an exception in this case, right?
e
I just double checked.. (See image) null primitives are deserialized into non-specified default (feature?), non-nullable object actually throws which is nice. Could be I got the cause mixed up when hibernate was involved in the mix. KotlinX would throw exception in both cases.
With a default value specified 🙈
r
@thanksforallthefish By using kotlinx.serialization instead of jackson, you can have exactly the same serialization format on both the client and the server, where client can be Kotlin/JS or other target unsupported by jackson. You can also share the Serializers for custom types (e.g. Date/Time). I've also experienced problems with Jackson and Kotlin sealed class hierarchies.
🙏 1
b
believe it or not, this behaviour still exists and I just filed a bug report in https://github.com/spring-projects/spring-framework/issues/33138 which has been accepted