Action Jackson! Effective JSON processing in Spring Boot Applications by Joris Kuipers @ Spring I/O
Vložit
- čas přidán 12. 06. 2023
- Spring I/O 2023 - Barcelona, 18-19 May
Slides: www.slideshare.net/jkuipers/a...
GitLab repo: gitlab.trifork.nl/jorisk/acti...
JSON processing plays an important role in nearly all applications nowadays, and Jackson is the de-facto standard library for that. Most developers are therefore familiar with using it for simple (un)marshalling purposes, but never go beyond the basics. In this session Joris will show how to effectively configure and use Jackson, focusing on Spring Boot applications. Boot provides a lot of support for configuring ObjectMappers, which you can use directly but are also used internally by the framework for e.g. handling HTTP requests/responses or message conversion. Topics will include tuning mappings, using modules, applying views and using alternative parsing options like JSON Pointer and JsonPath, all illustrated through live demos. Don’t miss out on this presentation and become an Action Jackson yourself! - Věda a technologie
Everyone uses json, but few videos about it. Thank you so much.
Excellent. Thank you Joris.
Excellent! Thank you for such a great talk.
Great talk. Thanks for sharing your experience.
Excellent talk!! I really enjoyed it. Thank you Joris!
Very good talk where whe can see the interesting options we have to customaize the JSON serialization and deserialization
This is a very good talk for me, who's getting introduced to java and spring boot
Great talk (e.g. I didn't know about Views - seems sort of custom graphql can be implemented using it :).
@Joris, I have a question - is it possible to configure properly serialization/deserialization with lombok delegate feature ( lombok.experimental.Delegate) - or fields should always be present on the target class?
I'm not familiar with the particular Lombok feature, but in general I'd say that as long as you stick to property accessors (i.e. getters and setters) and constructors rather than direct field access it should all just be transparent
Does the new library passes all CVE vulnerabilities?
I can think on one reason to create an ObjectMapper instance without the builder: a client library (Do not want user configuration mess up your requests)
Yes, in the context of the talk I was referring to regular application code only: of course there are always reasons to not use Boot ;)
As you demonstrated the parameters example I was thinking what happens when folks use any kind of code obfuscation.
Obfuscation and reflection are not exactly friends, indeed: better to be explicit about everything, then
Even if you create an objectmapper in the controller. How do you ensure endpoints in that controller will use it?
It wouldn’t be very typical to do that in a controller if you rely on the framework to do the (un)marshalling for you. You’d rather configure the relevant HTTP message converter to use your custom ObjectMapper