Duplication of collections elements

[leonardoluiz]

Whats your runtime?

• Dozer version: 6.2.0
• OS version: Win 10
• JDK version: JDK8

Whats the problem?

When a class is configured with class level is-accessible="true", and a List attribute in this class is annotated with @mapping, the elements of that attribute are being duplicated.

Steps to reproduce:

1. Configure a class with is-accessible="true".

<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://dozermapper.github.io/schema/bean-mapping"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://dozermapper.github.io/schema/bean-mapping http://dozermapper.github.io/schema/bean-mapping.xsd">
  <mapping>
    <class-a is-accessible="true">Source</class-a>
    <class-b is-accessible="true">Destination</class-b>
  </mapping>
</mappings>

2. Map a collection attribute with @mapping

    public static class Destination {

        @Mapping
        private List<String> items;

Observed Results:

The destination attribute will have two elements (destination.items.size() = 2).

Expected Results:

The destination attribute should have the same number of elements found in the source object.

Link to GitHub repo with Unit test

https://github.com/leonardoluiz/dozer-testcases/blob/master/src/test/java/org/dozer/testcase/MappingDuplicatesCollectionItemsTest.java

[garethahealy]

@leonardoluiz ; it looks like you've committed a fix to your own branch, but not raised a PR. Can you raise a PR?

[orange-buffalo]

@garethahealy actually there are two possible fixes.

One is local to Mapping annotation processing - it helps to resolve the issue, does not break anything existing, but maybe it is too local and we can catch the same problem in other places.

The second fix is global for addFieldMapping method - if there is a duplicated mapping for a field detected, this method fails. It could be more promising, as in general case it is not clear how to proceed with multiple mappings for a field: which one should take priority? But with this fix there are many existing tests failing, so it is not clear if this is a proper way and probably it is not backwards compatible.

What do you think, what is the best way to proceed here?

[grubeninspekteur]

@orange-buffalo if the second solution prevents mappings like

<field>
<a>a</a>
<b>c</b>
</field>
<field>
<a>b</a>
<b>c</b>
</field>

Then this would break our production code. We use these in conjunction with map-null=false to map either-or fields.

[orange-buffalo]

@grubeninspekteur thank you for your feedback! It looks like the only option for us is to have a local fix for @Mapping processing. @leonardoluiz, could you please prepare a PR with this change?

[leonardoluiz]

PR submitted. Thanks! @garethahealy @orange-buffalo @grubeninspekteur

[orange-buffalo]

@leonardoluiz thank you!
@garethahealy is there any chance to release Dozer with this fix? Our project needs it to migrate to the 6.x.

[garethahealy]

@orange-buffalo ; done

• https://github.com/DozerMapper/dozer/releases/tag/6.4.0

[orange-buffalo]

@garethahealy many thanks, we appreciate this!