Use CsvMapper with ObjectMapper in the same Spring project

[abccbaandy]

I am trying jackson CSV feature, but I have some question:

1. Seems CsvMapper extends ObjectMapper. I think it's not possible define CsvMapper as Bean without touch Spring ObjectMapper bean?

2. CSV feature reuse many JSON annotation, is it possible have different config for CSV/JSON in the same POJO? For example: If I want ignore a field in CSV only, I put @JsonIgnore on the field. But it will affect ObjectMapper process that POJO too.

3. Use the same config for both CSV and Json. Mainly for have same behave for convert Java 8 time, locale...etc But I don't find something like setConfig(json.getConfig()), so I try to config one by one by myself.

       csvMapper.findAndRegisterModules();
       csvMapper.setConfig(jacksonObjectMapper.getSerializationConfig());
       csvMapper.setConfig(jacksonObjectMapper.getDeserializationConfig());
   
       //do other config in CSV only

   Is this enough? I don't find any issue for now though.

[cowtowncoder]

(1) Ok so I cannot comment on Spring side of things -- although do note there is also JsonMapper sub-type of ObjectMapper (although "plain" ObjectMapper is, for historical reasons, JSON-specific). Not sure if Spring could allow that separation.

(2) Unfortunately there is no such mechanism. It is something I have sometimes thought about, but have no good solution or ideas.

(3) Is tricky as well. I think your approach is reasonable, although the best (I think) would be to isolate configuration code in something reusable and call that on both mappers and not try to copy settings of an ObjectMapper. Copying settings is problematic and eventually something will probably not work right. So there is this:

https://github.com/FasterXML/jackson-databind/issues/3212

which would work for some cases, but I don't think it'd help here, as CsvMapper type itself is actually needed; and requires CsvFactory.

Given this, I think your approach is not unreasonable.

[abccbaandy]

(1) It's surprise to me that you can not comment Spring side things, Spring depend on jackson very heavily as I know.

(2) Sad to heard that 😢 Also it weird to use JSON annotation for csv feature, but I guess it's historical reason.

(3) I think you are right, but I can't do that because my ObjectMapper is from Spring auto config as you can see the ref. They do a lot of custom config instead simple new ObjectMapper(). This is why I am seeking csv.setConfig(json.getConfig()) feature.

ref: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration.java

[cowtowncoder]

On (1)... I develop Jackson, not Spring, so I do not really know much about how it works. I do know a lot about Jackson. Not sure why this would be surprising... Unless you were thinking I added Jackson-support in Spring? I didn't, there are lots of clever folks within Spring project who did that. :)

(2) Naming of annotations with Json prefix is historical artifact. Confusing, but they are not bound to JSON format in any way. Same is true for almost all Jackson types as well.

(3) yeah, I can see how it is problematic as initialization/config by the framework is not something you have control over. You can try using approach you are; I am only cautioning that there may be rough edges as direct setting (overriding) of SerializationConfig / DeserializationConfig is not really supported primary public API (it exists in Jackson 2.x for Jackson itself, needed).

[abccbaandy]

(1)

Unless you were thinking I added Jackson-support in Spring?

Yes....I thought such big level project will at least discuss with the author, instead just import it directly like us. :D

(3) I see, I will use my approach and see what happen then come back for help :P

[cowtowncoder]

(1) (on Spring) I do interact with Spring folks, but it definitely is more about them reporting bugs; I am just an occasional Spring (Boot) user, not developer. I don't have bandwidth to dig deep into implementations of any of frameworks (same is true about Quarkus, f.ex).

(3) yup!