[YANGTOOLS-1401] NormalizedNodeStreamWriterStack fails to initialize on choice nodes Created: 21/Feb/22 Updated: 21/Feb/22 Resolved: 21/Feb/22 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | data-util |
| Affects Version/s: | 7.0.14 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | High |
| Reporter: | Peter Puškár | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
image-2022-02-21-14-01-26-332.png
netconf-node-topology@2015-01-14.yang
network-topology@2013-10-21.yang
stacktrace.txt
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
NormalizedNodeStreamWriterStack fails to initialize on choice nodes because ChoiceEffectiveStatementImpl is not an instance of DataContainerNode. This happens when trying to create Nested writers in both JSONNormalizedNodeStreamWriter and XMLNormalizedNodeStreamWriter. This is the node I was trying to create Nested writer for: AbsoluteSchemaPath{path=[(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node, (urn:opendaylight:netconf-node-topology?revision=2015-01-14)credentials, (urn:opendaylight:netconf-node-topology?revision=2015-01-14)username]}AbsoluteSchemaPath{path=[(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node, (urn:opendaylight:netconf-node-topology?revision=2015-01-14)credentials, (urn:opendaylight:netconf-node-topology?revision=2015-01-14)username]}
The provided SchemaPath for that node looks as following: AbsoluteSchemaPath{path=[(urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)network-topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)topology, (urn:TBD:params:xml:ns:yang:network-topology?revision=2013-10-21)node, (urn:opendaylight:netconf-node-topology?revision=2015-01-14)credentials]}
Now I believe while serializing choice nodes, we should be able to initialize on the parent of that choice node, ie credentials in this case. If we should supply even one level higher, ie node in this case, this would require users to map the SchemaPath nodes against tree to just validate this one case and adjust the path accordingly. Then I consider this behavior as inconsistent. I would expect this code snippet to work for choice nodes as well: final SchemaPath path = SchemaPath.create(nodePath.stream() .filter(p -> !(p instanceof YangInstanceIdentifier.NodeIdentifierWithPredicates)) .filter(p -> !(p instanceof YangInstanceIdentifier.AugmentationIdentifier)) .map(YangInstanceIdentifier.PathArgument::getNodeType).collect(Collectors.toList()), true); final NormalizedNodeStreamWriter nestedWriter = JSONNormalizedNodeStreamWriter .createNestedWriter(codecSupplier.getShared(context), path.getParent(), null, jsonWriter); Correct me if I am using this wrong. |
| Comments |
| Comment by Robert Varga [ 21/Feb/22 ] |
|
Choice node is not part of the data tree, hence you cannot arrive at it through legal data tree lookup, hence it is not a DataContainerNode, hence it cannot be a root of data-based operations. If it could be, what would its XML element name be? |
| Comment by Peter Puškár [ 21/Feb/22 ] |
|
Okay so in that case, if it is invalid lookup I assume data tree should be empty then PathArguments just to check if we are on choice node and hence adjusting the starting node since neither PathArguments or SchemaNodes carry information on the type of node they represent.
|
| Comment by Robert Varga [ 21/Feb/22 ] |
|
Translation between YangInstanceIdentifier (i.e. yang-data-api addressing) and SchemaNodeIdentifier (and legacy SchemaPath) (i.e. yang-model-api addressing) always requires schema-informedness. Now you have taken the former, filtered some stuff out, ignored the the last item and told SchemaInferenceStack to take that and interpret it as an instantiated SchemaPath ... and that involves, as naming might suggest, walking the schema tree. So now: we have a variable called 'dataTree' because we fully expect it to point to a data tree node and we are checking whether that is really the case – and it is not, hence it is not a valid argument, hence we throw IAE. |
| Comment by Peter Puškár [ 21/Feb/22 ] |
|
That's what I suspected the problem is, the transition between data tree and schema tree. In that case, maybe we should expose some methods in JSONNormalizedNodeStreamWriter and XMLNormalizedNodeStreamWriter API that would directly allow us to provide path in data tree and initialize the Nested writers in data tree directly, correct? Since what we have now only allows us to provide SchemaPath as an argument and every other thing is in the end converted to SchemaPath as well (Absolute, EffectiveStatementInference). |
| Comment by Robert Varga [ 21/Feb/22 ] |
|
I believe you are mistaken: both SchemaNodeIdentifier and EffectiveStatementInference are interpreted verbatim, without going through SchemaPath. The two trees have a well-defined relationship (see RFC7950) and we provide all the tools necessary, so I really do not see a bug here. |
| Comment by Robert Varga [ 21/Feb/22 ] |
|
This is an issue of the caller, who needs to properly point the root at a data tree node. |
, which is not the case as you can see here.