Java – Dozer mapping JodaTime property not working as expected

dozerjavajodatimemapping

I am using Dozer to map between a Document class to DocumentManagementBean class, both of my own making. Both have a property, with getters and setters, of Joda DateTime type, called dateAdded.

When Document object d has property dateAdded=x, calling mapper.map(d, DocumentManagementBean.class) all fields get auto-mapped correctly (since I have full control over code base I am able to get away with no dozer-config and rely simply on matching property names), EXCEPT the dateAdded field, where the new DocumentManagementBean dmb ends up with the current DateTime in its dateAdded property, instead of x from the d object.

I am expecting Dozer to try to call

dmb.setDateAdded(d.getDateAdded());

and just bring the value of dateAdded from source to target, but it seems to be creating new DateTime for dmb object an then leaving it alone.

Can anyone shed some light on this for me please?

Best Answer

The basic problem is that Dozer creates a new blank instance of DateTime, via new DateTime(), and thats how you end up with the current date/time instead of the original one. There might be multiple solutions, I usually went with a customconverter, globally defined:

    <converter type="de.kba.resper.customconverter.DateTimeCustomConverter">
        <class-a>org.joda.time.DateTime</class-a>
        <class-b>org.joda.time.DateTime</class-b>
    </converter>

and

public class DateTimeCustomConverter extends DozerConverter<DateTime, DateTime> {

    public DateTimeCustomConverter() {
        super(DateTime.class, DateTime.class);
    }

    @Override
    public DateTime convertTo(final DateTime source, final DateTime destination) {

        if (source == null) {
            return null;
        }

        return new DateTime(source);
    }

    @Override
    public DateTime convertFrom(final DateTime source, final DateTime destination) {

        if (source == null) {
            return null;
        }

        return new DateTime(source);
        }

}

It may overdo it, though :)

Related Topic