If a concrete class has a subclass and a mapping is provided for the subclass, it is not honoured when mapping a collection, rather the superclass object is instantiated. See test case provided.
I've patched the Dozer code to address the issue. As far as I see it, subclass mappings should be honoured when mapping a collection element, but if you're not mapping a collection element, subclass mappings should not be used in place of the requested mapping. E.g.
public class A (
)
public class B extends A {
}
If mapping a Collection<A> and the collection contains a B and a mapping for B is provided, a B should be instantiated. However, if a request is made to map an A but no explicit mapping for A is provided, a B should *not* be returned. As such, I added a flag to indiciate if we're processing a mapping element -- if we are it's ok to return a subclass even if the requested class (as determined by the collection type) is an A.
I've attached a test case to reproduce the issue, and the modified Dozer files with our fix. Ref the fix, note the 'collection' flag passed from the MappingProcessor through to the ClassMappings. It is used in the findInterfaceMapping method.
Could you take a look at patching this for the next release, please? Either with the proposed fix or if you think there're issues with it, a different fix?
Many thanks,
Henry
Test case to recreate.
Proposed patch to fix.