You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I set up 2 ObjectMappers (one per api version) : the last version uses the default ObjectMapper (created by Spring Boot), and i instantiate an other ObjectMapper for the version 1 (there is different settings for the dates, the null fields, and so on).
I also need to build a Jackson Filter at runtime (the filter depends on the roles of the authenticated user), for that i can use the MappingJacksonValue wrapper. But when the values are wrapped, Spring will always use the default ObjectMapper.
We can see here that the ObjectMapper is selected before unwraping the value:
ghostd
changed the title
MappingJacksonValue and Jackson2CodecSupport#registerObjectMappersForType does not work together
MappingJacksonValue and Jackson2CodecSupport#registerObjectMappersForType do not work together
Feb 13, 2022
Indeed selectObjectMapper should ignore the MappingJacksonValue wrapper. Before selectObjectMapper was introduced we haven't had to consider the wrapper, e.g. in canEncode. It just hasn't come up as an issue but arguably that should also be checking against the value type.
Spring Framework 5.3.15
Spring Boot 2.6.3
I set up 2
ObjectMapper
s (one per api version) : the last version uses the defaultObjectMapper
(created by Spring Boot), and i instantiate an otherObjectMapper
for the version 1 (there is different settings for the dates, the null fields, and so on).I also need to build a Jackson Filter at runtime (the filter depends on the roles of the authenticated user), for that i can use the
MappingJacksonValue
wrapper. But when the values are wrapped, Spring will always use the defaultObjectMapper
.We can see here that the
ObjectMapper
is selected before unwraping the value:spring-framework/spring-web/src/main/java/org/springframework/http/codec/json/AbstractJackson2Encoder.java
Lines 195 to 211 in 4eaee1e
Is that "by design" or is this a missing feature?
Sample code:
Expected results:
"/v1/wrapped-hello" should return the same serialization than "/v1/hello"
The text was updated successfully, but these errors were encountered: