#140 losing custom-converter with inheritance-mapping

[Florian Kammermann]

Here ist the xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mappings PUBLIC "-//DOZER//DTD MAPPINGS//EN"
"http://dozer.sourceforge.net/dtd/dozerbeanmapping.dtd" [
<!ENTITY XMLBeanFac "net.sf.dozer.util.mapping.factory.XMLBeanFactory">
<!ENTITY PedasIdDlamEnumConv "ch.post.pf.dlam.svr.pedas.converter.PedasIdDlamEnumConverter">
<!ENTITY PedasYearDlamDateConv "ch.post.pf.dlam.svr.pedas.converter.PedasYearDlamDateConverter">
]>

<mappings>
<configuration>
<stop-on-errors>true</stop-on-errors>
<date-format>MM/dd/yyyy HH:mm</date-format>
<wildcard>true</wildcard>
</configuration>
<!-- Mapping for PersonGDT and Person -->
<mapping>
<class-a bean-factory="&XMLBeanFac;">
ch.post.pf.pedas.xmlbeans.type.gdt.PersonGDT
</class-a>
<class-b>ch.post.pf.dlam.svr.persistence.pdo.Person</class-b>
<field>
<a>GDOVersion</a>
<b>gdoVersion</b>
</field>
<field>
<a>personOID</a>
<b>oid</b>
</field>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>sprache</a>
<b>sprache</b>
</field>
</mapping>

<!-- Mapping for NatuerlichePersonGDT and NatuerlichePerson -->
<mapping>
<class-a>
ch.post.pf.dlam.svr.persistence.pdo.NatuerlichePerson
</class-a>
<class-b bean-factory="&XMLBeanFac;">
ch.post.pf.pedas.xmlbeans.type.gdt.NatuerlichePersonGDT
</class-b>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>aufenthaltsbewilligung</a>
<b>aufenthaltsbewilligung</b>
</field>
<field custom-converter="&PedasYearDlamDateConv;" type="one-way">
<a>aufenthaltsbewilligung</a>
<b>aufenthaltsbewilligung</b>
</field>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>geschlecht</a>
<b>geschlecht</b>
</field>
<!-- Field mapping for Namen -->
<field custom-converter="&PedasIdDlamEnumConv;">
<a>nameZusatz</a>
<b>nameZusatz</b>
</field>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>nationalitaet</a>
<b>nationalitaet</b>
</field>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>titel</a>
<b>titel</b>
</field>
<field custom-converter="&PedasIdDlamEnumConv;">
<a>anrede</a>
<b>anrede</b>
</field>
<field-exclude>
<a>geburtsdatum</a>
<b>geburtsdatum</b>
</field-exclude>
</mapping>
</mappings>

NatuerlichePerson inherit from Person.
The beans with the name gdt are xml-beans. The Problem is now, that the custom-converter defined on Person is lost on the way, and the mapper try to map without custom-converter. This causes obvious an exception.
the field sprache exists only on the types Person/PersonGDT.

I debug this problem now since 4 hours (in the dozer-source) but I don't see what's the problem.

In another mapping file I use the same style of mapping with custom-converter on a parent class. The only difference is, that the bean is not created by a bean-factory and the name of the attributes are different.

Ok, changed the name of the dest-attribute to sprache1 and now see, the convertion functions.
Seems like the following case fails:
- inheritance mapping
- custom-converter defined on a field of the parent-class
- the field-names are identical

[Florian Kammermann]

Logged In: YES
user_id=1607595
Originator: YES

Tried to exclude the field. But every constelation failed:
- exclude on child-class
- exclude on parent-class
- exclude on parent- / child-class

dozer would every-time map the field with the standard-mapper, which failed.

Perhaps you can me explain a little bit how this functions with the class-maps and the superclass-types. Then I can provide a patch.

Ah yeah, I forgott to say that we work with the version 3.4, cause in the version 4.2 the inheritance-mapping is more broken than in version 3.4.

Cheers haschibaschi

[Florian Kammermann]

Logged In: YES
user_id=1607595
Originator: YES

I think the bug is on line 1025 from the MappingProcessor. There the orginal field-mappings get overwritten with false ones. I think we need to check if there are original ones available with special configuration before overwrite them.

[Florian Kammermann]

Logged In: YES
user_id=1607595
Originator: YES

I forget to say that I have tested this with the versions 3.4, 4.0, 4.1, 4.2. And the failure appeared in every version. In version 4.1 and 4.2 the failure appeared but didn't throw an exception which terminates the thread. But in this versions it have other problems with inheritance which break my other mappings.

[Florian Kammermann]

Logged In: YES
user_id=1607595
Originator: YES

Ok I located the bug (or feature ;-)). The problem makes this piece of code:

// Fix for bug # [ 1486105 ] Inheritance mapping not working correctly
// We were not creating a default configuration if we found a parent level class map
if(mapping.getSourceClass().getClassToMap() != sourceClass
|| mapping.getDestClass().getClassToMap() != destClass) {
// there are fields from the source object to dest class we might be missing. create a default mapping between the two.
mapping = ClassMapBuilder.createDefaultClassMap(globalConfiguration, sourceClass, destClass);
superClasses.add(mapping);
}

Its in the MappingProcessor on line 1020 (version 3.4).

The problem is that I come here with an XMLBean-object, so the this statement "mapping.getSourceClass().getClassToMap() != sourceClass" is true, cause in the mapping-xml I declare the interface to map. Cause its true the MappingProcessor overwrites my custom-converters.

I don't understand really the logic, but perhaps we must check if the "mapping.getSourceClass().getClassToMap()" is assignable to the Class (in my case an interface) "sourceClass". And only create the default mapping when it isn't assignable.

I found a workaround:

First I declare the XMLBean-implementation in the mapping file. This breaks the functionality of the Factory but worksaround the bug in the Mappingprocessor. Then I extended the XMLBeanfactory and change the name of the XMLBean-implementation into the name of the interface, before I instantiate the Bean.

Cheers Flo