#126 parent-child not work

Dozer v.4.3
closed-fixed
5
2008-11-18
2008-01-07
ed
No

Hellu,

Like stated in my forum post:
http://sourceforge.net/forum/forum.php?thread_id=1864420&forum_id=452530
the parent-child relation still not work properly.

That is: suppose I have class child, parent and grandparent.
The grandparent contains a field id with accessors.
This field id will not be mapped in a child mapping. Even not when it's contained in the xml mapping file

However, it will be properly mapped when the id mapping definition is contained in the parent mapping definition.
I had the same for other fields.

So the problem is that only xml field mapping definitions from the direct parent are inherited and not from the grand parent... (only one level deep).

Hope this is enough information.
This bug was produced aleardy in 4.1 and not solved in 4.2

Cheers,
Ed

Discussion

  • Roman Krejcik

    Roman Krejcik - 2008-03-25

    Logged In: YES
    user_id=2045378
    Originator: NO

    I have same problem. Deep hierarchy mapping (more then direct parent) doesn't work.
    Probably bug in MappingProcessor.checkForSuperTypeMapping() method (and maybe in another place)

     
  • Agoria

    Agoria - 2008-10-23

    Hi,

    we're also facing this problem here.

    grand parent mapping for not simple types (String, Integer...) does not work.

    in method checkForSuperTypeMapping there's a loop nested in another one and just before running into the nested one, superDestClass variable should be reinitialized.

     
  • ed

    ed - 2008-11-14

    Hi,

    The probleem is indeed in the method checkForSuperTypeMapping:
    It contains 2 while loop: the outer one loops through the superSrcClass and the inner one through the superDestClass.
    When the inner loop is finished and the superSrcClass is changed, the superDestClass isn't reset such that it won't go through the inner loop again, such that it only does it one time (just like I mention in the above text).
    Simple adding one line of code that give resets this value at the beginning of the outer while will work just fine:

    Class superDestClassOrg = MappingUtils.getRealSuperclass(destClass); // CHANGED
    Class superDestClass = superDestClassOrg; // NEW
    boolean stillHasSuperClasses = true;
    while (stillHasSuperClasses) {
    if ((superSrcClass != null && !superSrcClass.getName().equals("java.lang.Object"))
    || (superDestClass != null && !superDestClass.getName().equals("java.lang.Object"))) {
    superDestClass = superDestClassOrg; // NEW

    This does the trick.
    I just bounced in to this as I am busy solving another nasty bug that I still have to post: the bug will be solved when (in the same method as above):
    Set superClasses = new HashSet();
    will be replaced by an ArrayList as the order need to be fixed and the parent classes MUST be MAPPED completely first. A set don't have this fix order such that the order is random that can give verryyyyy nasty bugs that only show them self sometimes.
    I want to rewrite his whole function to a recursive version.
    Let's see how far I get...
    See the bug that I still have to post (including a patch probably).....

     
  • ed

    ed - 2008-11-14

    Hi,

    The probleem is indeed in the method checkForSuperTypeMapping:
    It contains 2 while loop: the outer one loops through the superSrcClass and the inner one through the superDestClass.
    When the inner loop is finished and the superSrcClass is changed, the superDestClass isn't reset such that it won't go through the inner loop again, such that it only does it one time (just like I mention in the above text).
    Simple adding one line of code that give resets this value at the beginning of the outer while will work just fine:

    Class superDestClassOrg = MappingUtils.getRealSuperclass(destClass); // CHANGED
    Class superDestClass = superDestClassOrg; // NEW
    boolean stillHasSuperClasses = true;
    while (stillHasSuperClasses) {
    if ((superSrcClass != null && !superSrcClass.getName().equals("java.lang.Object"))
    || (superDestClass != null && !superDestClass.getName().equals("java.lang.Object"))) {
    superDestClass = superDestClassOrg; // NEW

    This does the trick.
    I just bounced in to this as I am busy solving another nasty bug that I still have to post: the bug will be solved when (in the same method as above):
    Set superClasses = new HashSet();
    will be replaced by an ArrayList as the order need to be fixed and the parent classes MUST be MAPPED completely first. A set don't have this fix order such that the order is random that can give verryyyyy nasty bugs that only show them self sometimes.
    I want to rewrite his whole function to a recursive version.
    Let's see how far I get...
    See the bug that I still have to post (including a patch probably).....

     
  • dmitry (lv)

    dmitry (lv) - 2008-11-18
    • labels: --> Mapping Issue
    • milestone: --> Dozer v.4.3
    • assigned_to: nobody --> buzdin
    • status: open --> closed-fixed
     
  • dmitry (lv)

    dmitry (lv) - 2008-11-18

    Bug is fixed. Fix will be included in release 4.3.
    Thank you for your comments. It helped to solve the issue.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks