Menu
▾
▴
#68 Regression: inherited setters not found in XMLBeans classes
Following on from defect 1636354 I've isolated the problem I'm seeing in my real code, and this problem is a regression in Dozer 2.4 (the same unit tests pass with Dozer 2.2 and 2.3).
Basically what's happening is that Dozer is unable to find the setters for the "inherited" fields - it throws the following exception:
net.sf.dozer.util.mapping.MappingException: Unable to determine write method for field: id class: interface net.pmonks.xml.dozer.test.ChildType
at net.sf.dozer.util.mapping.propertydescriptor.BruteForcePropertyDescriptor.getWriteMethod(BruteForcePropertyDescriptor.java:142)
at net.sf.dozer.util.mapping.propertydescriptor.BruteForcePropertyDescriptor.getWriteMethod(BruteForcePropertyDescriptor.java:260)
at net.sf.dozer.util.mapping.propertydescriptor.BruteForcePropertyDescriptor.getPropertyType(BruteForcePropertyDescriptor.java:63)
at net.sf.dozer.util.mapping.fieldmap.FieldMap.getDestFieldType(FieldMap.java:78)
at net.sf.dozer.util.mapping.MappingProcessor.mapFromFieldMap(MappingProcessor.java:313)
at net.sf.dozer.util.mapping.MappingProcessor.mapField(MappingProcessor.java:277)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:230)
at net.sf.dozer.util.mapping.MappingProcessor.processSuperTypeMapping(MappingProcessor.java:1026)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:222)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:136)
at net.sf.dozer.util.mapping.MappingProcessor.map(MappingProcessor.java:110)
at net.sf.dozer.util.mapping.DozerBeanMapper.map(DozerBeanMapper.java:108)
at net.pmonks.dozer.test.DozerTest.testPojoToXmlBean(DozerTest.java:43)
I've attached a JUnit test that demonstrates this problem - it's virtually identical to the test case attached to defect 1636354, but with one change: the "inherited" fields are explicitly listed in the mappings file to workaround the (broken) wildcard mapping problem described in that defect report.
JUnit Test Case demonstrating the problem
Logged In: YES
user_id=1236069
Originator: NO
I was able to recreate the issue using your test case. I think both bugs(this and 1636354) are caused by the same root cause. I don't think it is specific to XMLBean objects. The problem appears to be with apache commons bean utils PropertyUtils.getPropertyDescriptors(). Dozer uses this api internally to introspect data objects via reflection. The getPropertyDescriptors doesn't return the correct results when you have interface inheritance. If you run the following you will see the problem. It does not return the properties in the super interface. This is not a problem with concrete classes though. I am investigating alternatives.
PropertyDescriptor[] pds = PropertyUtils.getPropertyDescriptors(net.pmonks.xml.dozer.test.ChildType.class);
Logged In: YES
user_id=1236069
Originator: NO
PropertyUtils.getPropertyDescriptors() just calls Introspector.getBeanInfo(), so this is where the root cause seems to be. I believe the interface inheritance issue with Introspector is a known issue. I am looking for alternatives
Logged In: YES
user_id=1236069
Originator: NO
I have a fix for this defect, but not for #1636354 which is caused by the same root problem with Introspector.
To resolve this defect, I modified the dozer code to use the actual runtime class when introspecting to find read/write methods. Before it was using the class specified in the mapping file. So if class specified in the xml file was an IF, at runtime dozer would use the IF class for introspection. Using the runtime implementation may be a good thing anyways and may resolve some of the strange "could not determine read/write" runtime errors that have been reported. I wonder if these use cases had interface inheritance?? This may also resolve some of the other strange errors with proxied classes that have been reported in the past, but it's hard to say for sure. After making these changes, all regression tests ran green and performance numbers didn't change.