-
Bug
-
Resolution: Duplicate
-
High
-
None
-
None
-
None
On resolving relative paths for key_leaf1 and leaf2 leafrefs(with findDataSchemaNodeForRelativeXPath) SchemaContextUtil.resolveRelativePath() returns incorrect paths.
module
module a { yang-version 1; namespace "a"; prefix "a"; grouping foo_grp { leaf key_leaf1 { type leafref { path "../../../../../../a:foo_cont/a:name"; } } } container bar_cont { leaf leaf2 { type leafref { path "../../../../../../a:foo_cont/a:name"; } } } }
Incorrect paths:
for key_leaf1: [(a)foo_grp, (a)key_leaf1, (a)foo_cont, (a)name]
for leaf2: [(a)bar_cont, (a)leaf2, (a)foo_cont, (a)name]
On call findDataSchemaNodeForRelativeXPath with leaf2 fails with
java.lang.IllegalArgumentException: Path [(a)bar_cont, (a)leaf2, (a)foo_cont, (a)name] extends beyond terminal child
On call findDataSchemaNodeForRelativeXPath with key_leaf1 returns null.
Let's check whether the path goes behind grouping root node or root node of a different type. With this improvement, we will not lookup knowingly incorrect paths.
- duplicates
-
YANGTOOLS-1229 Rework SchemaContextUtil.getBaseTypeForLeafRef()
- Resolved
- relates to
-
YANGTOOLS-1216 Require QName instead of SchemaPath for TypeDefinition implementions
- Resolved