Question

I'm using CsvDozerBeanWriter to write a bean instance to a CSV file. Following the example code I've used CsvDozerBeanWriter#configureBeanMapping(...) before writing the bean to CSV. Everything works well except when the bean has String attributes that are empty (rather than null). I find that such attributes are not copied from the bean to the intermediate CsvDozerBeanData instance before writing. This causes an exception as the number of columns then don't match the number of cell processors.

Digging in I found that configureBeanMapping(...) performs the equivalent of setting Dozer's map-empty-string to False. All empty strings are therefore not mapped (null strings still get mapped).

How do I overcome this? Is providing my own DozerBeanMapper (as the documentation says) the best way to go?

Update:

Here are the details of the exception I got:

 org.supercsv.exception.SuperCsvException: The number of columns to be processed (7) must match the number of CellProcessors (12): check that the number of CellProcessors you have defined matches the expected number of columns being read/written
context={lineNo=2, rowNo=2, columnNo=1, rowSource=[a, b, c, d, e, f, g]}
org.supercsv.exception.SuperCsvException: The number of columns to be processed (7) must match the number of CellProcessors (12): check that the number of CellProcessors you have defined matches the expected number of columns being read/written
context={lineNo=2, rowNo=2, columnNo=1, rowSource=[a, b, c, d, e, f, g]}
    at org.supercsv.util.Util.executeCellProcessors(Util.java:78)
    at org.supercsv.io.dozer.CsvDozerBeanWriter.write(CsvDozerBeanWriter.java:133)

The bean has String attributes a through l. Attributes h through l are empty strings.

Update 2:

Here is a test case.

Was it helpful?

Solution

If map-empty-string is disabled, then the value passed to the cell processors should be null (i.e. you'd most likely get an error from the processor for that column saying the value shouldn't be null - not an exception about there being the wrong number of processors). If you could post the exception details to clarify this that would be great :)

After running some tests with CsvDozerBeanWriter, it looks like the Dozer mapping API was fixed in Dozer 5.4.0 (see this commit).

  • In Dozer 5.3.2 "" is mapped to null

  • In Dozer 5.4.0 "" is mapped to ""

Unfortunately there's no detailed release notes for Dozer 5.4.0 (and no issue created on GitHub - they're still in the process of being migrated from SourceForge) to make this easier to find out.

If you can upgrade to Dozer 5.4.0, then that should fix your problem. I'm planning on upgrading Super CSV to Dozer 5.4.0 in the next release (early next year), but there's nothing stopping you from overriding the version inherited from Super CSV right now.

If you're stuck on Dozer 5.3.2 for some reason, then I'd suggest you either:

  • write your own Writer that extends CsvDozerBeanWriter (but override the configureBeanMapping() method to provide a MappingBuilder that has map-empty-string enabled)

  • use CsvBeanWriter (if you're not using indexed/deep mapping)

FYI I encountered another bug with the mapping API in 5.3.2 that meant I had to enable map-null at the class level instead of the mapping level when writing CsvDozerBeanWriter- this has also been fixed in 5.4.0 (though Super CSV will function correctly with either version of Dozer).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top