[YANGTOOLS-535] NPE when reading an object generated from a choice statement Created: 23/Oct/15  Updated: 10/Apr/22  Resolved: 28/Oct/15

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

Type: Bug
Reporter: Lori Jakab Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 4520

 Description   

Trying to get an object generated from a choice statement including both leaf and container results in a NPE. I'm not 100% sure that the NPE is caused by the combination of leaf and container, but there it is. The model used resembles the following:

grouping object {
choice type {
leaf simple-type

{ type int; }

container complex-type

{ uses some-grouping; }

}
}

Real version at [1].

The object grouping is used as the input for an RPC. When trying to call RPCInput.getObject().getType() the NPE is thrown. Same result if the grouping is used for RESTCONF input, when reading the generated objects. Here are the relevant first few lines (based on the real model):

java.lang.NullPointerException
at org.opendaylight.yangtools.binding.data.codec.impl.ChoiceNodeCodecContext.deserialize(ChoiceNodeCodecContext.java:157)
at org.opendaylight.yangtools.binding.data.codec.impl.ChoiceNodeCodecContext.deserializeObject(ChoiceNodeCodecContext.java:169)
at org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.getBindingChildValue(DataObjectCodecContext.java:329)
at org.opendaylight.yangtools.binding.data.codec.impl.LazyDataObject.getBindingData(LazyDataObject.java:122)
at org.opendaylight.yangtools.binding.data.codec.impl.LazyDataObject.invoke(LazyDataObject.java:69)
at com.sun.proxy.$Proxy81.getAddress(Unknown Source)
at org.opendaylight.lispflowmapping.implementation.MappingService.addKey(MappingService.java:140)

[1] https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=mappingservice/lisp-proto/src/main/yang/lisp-address-types.yang;h=a2ba43c8eb669e1f1bd52e14772ea546392c1909;hb=refs/heads/topic/ietf_yang

 Comments   
Comment by Vratko Polak [ 23/Oct/15 ]

Is this just another symptom of YANGTOOLS-524?

Comment by Lori Jakab [ 23/Oct/15 ]

I will check if the proposed fix for YANGTOOLS-524 helps.

Comment by Martin Ciglan [ 28/Oct/15 ]

Hi

YANGTOOLS-524 was merged to master, can you try it again, please?

Comment by Lori Jakab [ 28/Oct/15 ]

I just checked, the issue is now fixed.

The problem was not mixing leaves and containers under `choice`, but rather the lack of a `case` statement for each choice, because by adding a `case` statement also fixed the issue.

But now it works without the `case` statement too.

Comment by Martin Ciglan [ 28/Oct/15 ]

real issue was case-shorthand stated in GROUPING.

Glad to hear it works. Thank you.

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