#353 Mapping does not handle unmodifiable List

[Oliver Sauder]

The Java JDK class java.util.Collections provides methods to make a list unmodifiable.

This might be used e.g. when setter of a list does some more than just setting e.g. setting a parent (quite usual with EJB/JPA) on any entry of the list. To force this behavior the getter of the list only returns a unmodifiable list.

However Dozer does not take care of such a list.

I have attached a patch which fixes this issue + a test. Unfortunately, Collections.unmodifableList is not accessible so I had to do some String comparison.

Patch built against trunk.

[Oliver Sauder]

[Fuzail Sarang]

I believe this is handled by simple declaring this as field access, I know this due to our system using hibernate and us declaring field level access for any collections that use Collections.unmodifableList on there getters.

[Oliver Sauder]

That was the first thing I have tried. However when using field access the setter will never be called

As the setter is in charge of setting the parent on any object of the list, new objects in the list won't be assigned to any parent.

So this workaround only works for updating existing items in the list but not adding new ones.

[Fuzail Sarang]

Yep even for bidirectional relationships we have this working by havinmg mapping entries for both sides of the relationship, only falls short if there is additional logic in the setter other than just setting the parent object or if the object being transformed from doesn't maintain bi-directionality as well. I have written some code that does maintenance for such scenarios, immediately looking at the patch this will be problematic for anyone that uses hibernate as the patch is creating a new list as the destination which means hibernate users would incur a performance hit and loss of the persistent context for their collection.

[Oliver Sauder]

We do not have bidirectional mapping for our enterprise beans for many reasons (although I do not see that such would help in our situation). And I think it should not be the case that beans need to be adjusted so dozer mapping works.

But I see that such a change as suggested in the patch can be critical when a setter is implemented that the hole persistence list will be replaced. (although not sure if such a setter is useful in other cases).

Just for clarification here a snippet how one of our setter looks like:
public void setAddresses(List<CustomerAddress> addresses)
{
this.addresses.clear();
for(CustomerAddress addr : addresses)
{
addr.setCustomer(addr);
addresses.add(addr);
}
}

However I was thinking about a new attribute on a field e.g. called wrap-list which would do this wrapping instead of checking for unmodifiable. wrap-list is set to false per default. This would be 100% backwards compatible, avoiding side effects but still give the user the chance to wrap its list when needed.