Details
-
Improvement
-
Status: Resolved
-
Medium
-
Resolution: Done
-
None
-
None
Description
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.
Attachments
Issue Links
- is blocked by
-
MDSAL-182 Java binding v1: leafref up two containers not found if from grouping
- Resolved
- relates to
-
MDSAL-528 Failed to find leafref target using specific combination of leafref and grouping
-
- Resolved
-
-
MDSAL-533 Generated code with incompatible types
-
- Resolved
-
-
MDSAL-651 yang-maven-plugin:6.0.2 error while generating sources
-
- Resolved
-
-
MDSAL-518 leafref path outside of augmented scope can not be resolved
-
- Resolved
-
-
MDSAL-732 Binding generator generates uncompilable code for leafref chain with identityref at the end
-
- Resolved
-