[YANGTOOLS-262] unable to refine grouping where field in grouping was an extension Created: 11/Aug/14  Updated: 10/Apr/22  Due: 22/Aug/14  Resolved: 20/Aug/14

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Giles Heron Assignee: Martin Vitez
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC

Attachments: Zip Archive opendaylight.zip    
External issue ID: 1524

 Description   

a YANG submodule has a statement of the form:

uses foo {
refine bar

{ ... }

}

this fails in parsing with an error along the lines of:

"Refine target node bar not found."

grouping foo is defined in the same module and only contains bar. However bar is defined using a vendor extension

grouping foo {
vendor:extension bar

{ ... }

}

I'm guessing ODL isn't happy with the vendor extension...

 Comments   
Comment by Giles Heron [ 11/Aug/14 ]

Attachment opendaylight.zip has been added with description: zipped Opendaylight log file

Comment by Martin Vitez [ 18/Aug/14 ]

This issue was fixed by https://git.opendaylight.org/gerrit/#/c/9574/.
The problem is that yangtools doesn't support refinement of extension instances at this time. This patch makes parser log a warning that target of refinement was not found and continue parsing without throwing an exception (refinement process is ignored).

Comment by Giles Heron [ 19/Aug/14 ]

so the bug I raised below was against a release that already had this "fix" in it. The warning seems to result in the module not parsing successfully (certainly the module doesn't seem to be accessible after the netconf server is mounted).

Comment by Tony Tkacik [ 20/Aug/14 ]

Warning should still be raised (refining uses of extension) so user is aware that we are not doing it (since we do not know semantic of that extension, and we are not sure if extension was refined by accident or by intent.

Generated at Wed Feb 07 20:52:43 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.