Dozer mapping stops working #118
Comments
|
Sounds like it is the same bug :#121 |
|
If it's a JDK's bug it shouldn't happen on 7u51-2.4.5-2 because it's supposed to be fixed in 7u40. But it does, unfortunately. I couldn't find the pattern but it disappears after I restart jetty and can appear again another day. My DTO class doesn't involve generics so that bug doesn't apply. The failing method (setParent) isn't declared in the base class (though getParent() does). Never was a case with OpenJDK 6. |
|
@bleshik This issue is widely reported online in the recent months, and is not related to the JDK bug you have linked in your post. Here is an excerpt from the JDK site you linked: "If the read method is defined on the target class but the write method is declared in the base class, the generated PropertyDescriptor does not have the write method. The change in behavior is limited to properties that are defined between the target class and a super class in the class hierarchy. This seems to only affect properties that involve generics. Both the read and write methods are available if both members are defined in the same class or if their type does not involve generics." First of all, in the examples I've come across and in my own case, the read and write methods are all on the same class. Secondly, the methods do not contain generics. So this is still an active bug in Dozer and needs to be addressed. |
|
With (Sun/Oracle) JDK 6, you have also problems without generics: https://issues.apache.org/jira/browse/BEANUTILS-443 I don't know exactly how, but org.springframework.beans.BeanUtils has solved this problem (it also solved some problems with generics) |
|
I'm just wondering if this issue is fixed? I can't figure out if this fix has been already release or not? |
|
I can't reproduce this, but having read the discussions and the suggestions I committed 2cd9322, which hopefully fixes the issue. @buzdin, care to review the commit? The approach used by @ssiahetiong is another alternative; whatever we pick, this needs to be sorted in 5.5.2. Those affected - @heneke, @cedricbompart, @wschmitz, @rkfg - do you have the possibility to try out the latest version from the repo and see if it resolves the problem? |
|
I will try the fix. I cannot reproduce the error on demand, but every once in a while it comes up. I'll post an update here if I run into the issue again. Thanks!! |
|
Sorry, it was an issue long time ago. I don't have it now, many components were updated since, both JRE and dozer. Thanks for the fix anyway, maybe it will help somebody. |
|
It occures occasionally (i think it depends on the garbage collection) in our test systems (all systems run with the JRE 7u51) with the 5.5.1 release. After i found this issue we used the current code base and deployt our application with the fix (mentioned above). |
|
Thank you for all your answers, i will try the fix and I will make a report to tell you if it's evreything is ok |
|
@wschmitz, @tofmonaute: Thanks! Please do let us know if the issue still continues after the fix. Alternatively, it's also useful to know if you can run Dozer for a longer period of time without the issue appearing. @waldemar-schneider, thanks for the info! Did you use c24164b or something else to fix this? |
|
@lauriharpf I think so. We used the codebase from the 3rd december. I can't say if there were another commits. We were a little bit desperate, because our client had these errors in their production environment :-( |
|
@lauriharpf I changed the code affected long time ago because the production system was affected. I completely removed dozer from the project, so I won't be able to test it. Sorry! |
|
Unfortunately our QA department was able to reproduce this error again with the fixed snapshot version from dozer two days ago :-( I should mention, that we use a interface (i just call it I think i read some posts that this issue occures if the get / set method for a property are defined on different class hierarchy levels. I don't know if the stacktrace is helpful, but i just post it here:
|
|
Yeah, that probably was it. I had my class implementing a Hierarchic interface that only had getParent() method. setParent() was declared in the class itself (as well as getParent() of course). Dozer couldn't find one of them, I don't really remember which one. |
|
@waldemar-schneider, thanks for the report and apologies for the issue not being resolved. The details you provided (stacktrace and description) do help, much appreciated. I'll look at this during Christmas holidays unless someone beats me to it. Quick question: Which commons-beanutils JAR are you using during runtime? 1.9.2 (shipped with Dozer) or is something else bringing in a different version? |
|
@lauriharpf It appears that jasper reports (5.1.0) also brings its own version of beanutils (1.8.2). Due to our maven structure of our modules and frameworks this has overriden the beanutils version of dozer. I didn't notice that until yesterday. thanks for the hint. |
|
we have this in our production system as well and we turned off this feature for now. so updating the beantutil to its latest version fixes this issue? or do we need to upddate both dozer and bean util? |
|
After we moved to a new BeanUtils Version (1.9.2) and moved getter and setter for the id (for more info, look at my previous post )into the same interface, this issue is no longer existent in our environment. |
|
Is there a possible way of not having to move getter and setter to same base as we've an usage where we override the getters and setters in children in source pojo but not in destination pojo? |
|
Hi, @lauriharpf , @buzdin , We have been using dozer version 5.2.2 in our application and we faced this issue recently on production. It is not reproducible on local set up. Can anyone confirm if the issue is fixed in the latest release 5.5.1 ? Or is there any other way of fixing it? |
|
I see this Pull request that is a fix for this issue I see it has come in after the 5.5.1 release. Is there going to be a new release so this bug fix can come out in an official build? If not, is the current master branch of this repo considered stable enough for people who use dozer in a production environemnet? |
|
Hi we are using dozer 5.2.2 and getting this exception... MapId: null Getters and Setters are in abstract super class. We are facing the issue only in Production not able to reproduce in Local. |
|
Hi, same problem for me, dozer mappings are instable in preproduction. When will you release the version 5.5.2 ? Or at least in beta ? Otherwise I will have to compile myself the trunk and push it in our nexus instance... |
|
Hi , |
|
Hi there, any update on this issue? Is this issue fixed on 5.5.1? |
|
My problem has been solved by replacing the common beanutils jar version to 1.8.3 (working fine from last two days after changing the mention beanutils version) and I am using dozer 5.3.2 version.Basically beanutils version mentioned in dozer pom. and second thing getter setter of a variable should not be in two diff interfaces in its respective hierarchy. |
|
Hi , 2017-02-14 18:11:58,241 ERROR [IBSOutboundProcess:124]: IBSOutboundProcessor DataAccessException occured for batch : 6ab7f78e-d75f-4866-b2ad-981597aa2d8f Some sample mapping :
|
|
I am also facing the same issue even after commonbeanutils-1.8.3 and dozer 5.3.2 and abstract setter is also in only one interface in interface hierarchy . Have anyone found any other solution for this. org.dozer.MappingException: java.lang.NoSuchMethodException: Unable to determine write method for Field: 'id' in Class: class |
|
@gauravtyagi77 ; can you build from latest source and retest please? |
|
Please re-test with 6.0.0 |
|
try adding default constructor in your class. |
and others
After a short amount of time (varies between hours up to one day), dozer mapping stop working with
org.dozer.MappingException: java.lang.NoSuchMethodException: Unable to determine write method for Field: 'xxxxx' in Class: class a.b.c.FooBar
at org.dozer.util.MappingUtils.throwMappingException(MappingUtils.java:82)
at org.dozer.propertydescriptor.GetterSetterPropertyDescriptor.invokeWriteMethod(GetterSetterPropertyDescriptor.java:261)
at org.dozer.propertydescriptor.GetterSetterPropertyDescriptor.setPropertyValue(GetterSetterPropertyDescriptor.java:101)
at org.dozer.fieldmap.FieldMap.writeDestValue(FieldMap.java:94)
at org.dozer.MappingProcessor.writeDestinationValue(MappingProcessor.java:870)
at org.dozer.MappingProcessor.mapFromFieldMap(MappingProcessor.java:337)
at org.dozer.MappingProcessor.mapField(MappingProcessor.java:276)
at org.dozer.MappingProcessor.map(MappingProcessor.java:245)
at org.dozer.MappingProcessor.map(MappingProcessor.java:187)
at org.dozer.MappingProcessor.map(MappingProcessor.java:124)
at org.dozer.MappingProcessor.map(MappingProcessor.java:119)
at org.dozer.DozerBeanMapper.map(DozerBeanMapper.java:111)
This is Dozer 5.3.2 on Java 1.7, but happens with 5.4.x also. It's never the same target class or field that fails.
This was already reported here: http://sourceforge.net/p/dozer/bugs/372/
The text was updated successfully, but these errors were encountered: