[MDSAL-426] Specialize relative leafref types during instantiation

Blocks — Sat, 12 Mar 2022 00:46:44 +0000

~~MDSAL-182~~ uncovers a case where a grouping definition cannot fully resolve the type of a leaf. The solution is to fall back to java.lang.Object.

This solution needs to be further improved, as in some cases we can determine what the type is, for example in:

    grouping foo {
        leaf foo {
            // java.lang.Object
            type leafref {
                path "../../bar";
            }
        }
    }

    container one {
        leaf bar {
            type string;
        }
        // leaf foo is java.lang.String
        uses foo;
    }

    container two {
        leaf bar {
            type uint16;
        }
        // leaf foo is java.lang.Integer
        uses foo;
    }

Both One and Two can specialize their return type to either String or Integer and have their Builders require the proper type. This obviously needs to work with groupings, too:

    grouping foo {
        leaf foo {
            type leafref {
                path "../../bar";
            }
        }
    }

    grouping one {
        leaf bar {
            type string;
        }
        uses foo;
    }

    container cont {
        uses one;
    }

This also means grouping copy builders need to take specializations into account and perform checkArgument() to determine if the source grouping actually has a compatible specialization.

OpenDaylight JIRA

[MDSAL-426] Specialize relative leafref types during instantiation