#193 remove-orphans not handled when mapping java.util.Map

Dozer v5.3.0

the mapMap() method in MappingProcessor doesn't take remove-orphans field map attribute into account. This makes mapping the maps onto existing maps hard.


  • GrzegorzOledzki

    GrzegorzOledzki - 2009-05-08

    For us it was enough to add:
    if (field == null) {
    // no destination map exists
    result = (Map) DestBeanCreator.create(srcMapValue.getClass());
    } else {
    result = (Map) field;
    if (fieldMap.isRemoveOrphans()) {

    in mapMap(...) method.

    I am not sure if this is inline with all the mapping use cases, so I don't submit it as a patch. Still someone may find it useful.

  • dmitry (lv)

    dmitry (lv) - 2009-10-06

    What is the expected behavior in this case? Should we treat values equal by their unique keys or values itself?

    I would propose keys. In this case mapping [1->a, 2->b'] onto [2->b, 3->c] would give [1->a, 2->b'] in case remove-orphans enabled.

  • dmitry (lv)

    dmitry (lv) - 2009-10-06
    • milestone: --> 929386
    • assigned_to: nobody --> buzdin
  • GrzegorzOledzki

    GrzegorzOledzki - 2009-10-06

    I would definitely agree. This would be compatible with standard java.util.Map contract. Note that Map#remove() operates on keys, not entries (keys+values).

    In other words. With remove-orphans set, the destination Map should have the same content as the source one (module custom setters, custom converters and stuff like that). I believe this is how Dozer handles collections in general.

  • dmitry (lv)

    dmitry (lv) - 2010-09-02

    fixed in trunk

  • dmitry (lv)

    dmitry (lv) - 2010-09-02
    • milestone: 929386 --> Dozer v5.3.0
    • status: open --> closed-fixed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks