Menu
▾
▴
#119 NullPointerException in Dozer 4.1
I received a NullPointerException in dozer 4.1. I'll attach the patch that we used to work around the problem. I'm not sure if the patch is correct, but it fixes the issue for us.
BTW, I think MappingProcessor.checkForSuperTypeMapping needs some review. I'm not sure it is doing what is intended (although I'm also not sure exactly what it is trying to accomplish :)). Looking at the code it looks like it only walks the destination superclasses once no matter how many source superclasses there are. My assumption is that the intent is to walk all of the destination superclasses for each source superclass.
Stack Trace:
java.lang.NullPointerException
at net.sf.dozer.util.mapping.util.ClassMapKeyFactory.createKey(ClassMapKeyFactory.java:34)
at net.sf.dozer.util.mapping.util.ClassMapKeyFactory.createKey(ClassMapKeyFactory.java:45)
at net.sf.dozer.util.mapping.MappingProcessor.checkForSuperTypeMapping(MappingProcessor.java:892)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:214)
at net.sf.dozer.util.mapping.MappingProcessor.mapCustomObject(MappingProcessor.java:454)
at net.sf.dozer.util.mapping.MappingProcessor.mapOrRecurseObject(MappingProcessor.java:417)
at net.sf.dozer.util.mapping.MappingProcessor.mapFromFieldMap(MappingProcessor.java:319)
at net.sf.dozer.util.mapping.MappingProcessor.mapField(MappingProcessor.java:265)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:234)
at net.sf.dozer.util.mapping.MappingProcessor.processSuperTypeMapping(MappingProcessor.java:932)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:218)
at net.sf.dozer.util.mapping.MappingProcessor.mapCustomObject(MappingProcessor.java:454)
at net.sf.dozer.util.mapping.MappingProcessor.mapOrRecurseObject(MappingProcessor.java:417)
at net.sf.dozer.util.mapping.MappingProcessor.addOrUpdateToList(MappingProcessor.java:739)
at net.sf.dozer.util.mapping.MappingProcessor.addOrUpdateToList(MappingProcessor.java:774)
at net.sf.dozer.util.mapping.MappingProcessor.mapListToList(MappingProcessor.java:646)
at net.sf.dozer.util.mapping.MappingProcessor.mapCollection(MappingProcessor.java:507)
at net.sf.dozer.util.mapping.MappingProcessor.mapOrRecurseObject(MappingProcessor.java:408)
at net.sf.dozer.util.mapping.MappingProcessor.mapFromFieldMap(MappingProcessor.java:319)
at net.sf.dozer.util.mapping.MappingProcessor.mapField(MappingProcessor.java:265)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:234)
at net.sf.dozer.util.mapping.MappingProcessor.processSuperTypeMapping(MappingProcessor.java:932)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:218)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:146)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:120)
at net.sf.dozer.util.mapping.DozerBeanMapper.map(DozerBeanMapper.java:94)
Patch against 4.1
Logged In: YES
user_id=550744
Originator: NO
Thanks. I will apply the patch and run our tests. If all goes well we can apply to our 4.2 release.
Franz
Logged In: YES
user_id=1236069
Originator: NO
I tried to apply the patch as is and it resulted in one of the unit tests hanging.
Updated Patch against 4.2
Logged In: YES
user_id=1061853
Originator: YES
File Added: Dozer_Bugfix1.patch
Logged In: YES
user_id=1061853
Originator: YES
We recently updated to 4.2 and have the same problem. I've attached another patch file. I was a little more aggressive with this patch. The problem is reproducible using cglib proxies. I've updated the unit tests to reproduce the problem. Applying the patch and reverting the change to MappingProcessor.java will reproduce the NPE.
As I stated in my previous notes, the code in the original implementation does not implement the stated intent in the comment. The comment made it appear that the code was to match every source superclass with every destination superclass. The previous code did not achieve that effect. I've rewritten the method to achieve that affect. All of the unit tests pass with my change.
If for some reason the change is not acceptable, please use my changes to the unit tests as a basis of identifying the problem.
This is fixed