Csv HttpMessageConverter [SPR-15457]

[spring-projects-issues]

Julien Bouyoud opened SPR-15457 and commented

Hi,

I'd like to submit a new HttpMessageConverter in spring-web module wich handle csv format.

Since csv is a schema like format, we needs to define it for each web-ressource.
Indeed, you may have multiple endpoints with same input data.

This purpose of this feature is to give to spring needed beans to defines those structured outputs.
I also suggest an implementation based on supra-csv library.
For now, this implementation support only serialization.
As exentention, i think it should be possible to move those schema definition by annotations (but needs more plumber to do this).

If you thinks this feature could be a part of spring-web, i can push a PR with those things.

Regards,
Julien

---

Reference URL: https://github.com/jBouyoud/spring-framework/tree/SPR-15457

[spring-projects-issues]

Brian Clozel commented

We already have an extensive support of Jackson - what do you think about jackson-dataformats-text CSV in that case? Wouldn't it require much less specific code in Spring Framework's codebase since the CSV schema is handled by Jackson itself (via annotations or a builder pattern)?

I don't see a lot of activity on this library, nor new releases planned at the moment.

I'll leave this issue opened for now and we'll see if other Spring developers think this might be useful and what library they've chosen.
Votes, comments describing actual use cases should help!

Thanks for your contribution!

[spring-projects-issues]

Julien Bouyoud commented

Unfortunately, I have no real experience with jackson-dataformats-text CSV.
As my opinion, I think that is a little bit strange to configure csv exports through @Json... annotations.
The major issue that I found in jackson-csv that is not support traversing object graph, so you need a DTO class definition of each exports and map your beans to those DTO before each export.

Otherwise, it could replace super-csv as well.
I think it's possible to refactor CsvMessage graph to be agnostic to the serialization library.

The purpose of this code base aims to answer to the following use cases :

• Handle huge amount of data with java8 Stream support
• Handle multiple schema in one file (called blocks)
  Eg: Data and then a block with data summaries
• Handle multiple (and dynamic) schema for one object graph

I hope this help
Julien

[plamentotev]

Hi,

We are looking into implementing CSV HttpMessageConverter using jackson-dataformats-text. Similar to the way MappingJackson2SmileHttpMessageConverter and MappingJackson2CborHttpMessageConverternd are implemented.

If you think that it might be useful to have Jackson CSV support in Spring we can provide merge request. But there are some caveats. Jackson Dataformat CSV has some limitations. Most importantly, as @jBouyoud mentioned, it does not support deeply nested structures. In other words you can't just return any POJO. It needs to be "flat". In our use case that is ok, because we have a separate endpoints that returns only CSV so we can have flat DTO specifically for this endpoint. But it may not work as expected if applied to all endpoints in a service. If you apply it to average RestController, chances are that exception will be thrown because the returned type is nested and thus not supported by Jackson Dataformat CSV. That is why I'm not sure if it is "generic" enough to be included as HttpMessageConverter in Spring. What do you think?

Another caveat is that the ObjectWriter returned by CsvMapper is not reusable for different classes. My understanding is that you need separate ObjectWriter for each class you serialize because you need to provide a schema for the serialization and the schema is type specific.

[bclozel]

There hasn't been many requests for this feature over the last years. I believe that our existing AbstractJackson2HttpMessageConverter, AbstractJackson2Decoder and AbstractJackson2Encoder provide a good basis for writing your own codec for the CSV format. We even added a simple version of that in a test recently written for #30493.

We don't aim to provide codecs for the numerous formats supported by Jackson and other libraries. Instead we can implement the infrastructure here in Spring Framework to unlock such cases.

I'm closing this issue as a result. Thanks for your contribution!