Operating System: All
Platform: All

Attachment shardingsimple.yang has been added with description: Yang model where the bug can be reproduced

Hi Jan,

I tested the attached model in the yang parser and all default values were filled out correctly in the produced SchemaContext.

Could you please provide more info, e.g. circumstances under which you ran into this problem or perhaps a unit test.

Thanks

This seems to be duplicate of
https://bugs.opendaylight.org/show_bug.cgi?id=2489

Hi Igor,

I retested the use case. The problem occurs for one specific case, when the json is entirely empty ( '{}'). I added one value for the input (test type) as follows:

{
"shard-test": {
"input":

}
}

and all the other values were filled in. I guess the problem is when no data whatsoever is specified (empty json) - I think for RPCs in that case all default values should be filled in.

To reproduce:

1. check our coretutorials in the current master:

> git clone https://git.opendaylight.org/gerrit/coretutorials.git

2. Go to the clustering/shardingsimple folder

> cd coretutorials/clustering/shardingsimple

3. Build:
> mvn clean install

4. Run the built distro:
> ./karaf/target/assembly/bin/karaf

5. Point the local browser at the controller - open
http://localhost:8181/index.html#/yangman/index (admin/admin)

6. Click on yangman, if the above URL did not get you there. Click on the shardingsimple model, then on operations, and then click the red SEND button. You will see the exception on ODL

After further discusion it seems it is a bug in md-sal. Hence the bug has been reopened and moved to md-sal.

Binding Aware LazyDataObject should be filling in default nodes, we need to create a unit test in binding-dom-codec

Based on the difference between when a single leaf is present and completely empty input, the problem is that nested DataObjects are not instantiated, leading to Input not being present.

This is an interesting side-effect of allowing nulls in invokeRpc() path. The idea that an RPC does not take arguments is not correct: RPC input statement is present implicitly and can externally be augmented – which implies that even RPCs that do not spell out an input statement still take an empty container as the argument. This then maps to the requested functionality: there is an input object which can have default leaves, as opposed to current mode of operation, when input is non-existent and there are not leaves.

MDSAL-303 tracks the change to DOMRpcService change required to make the input document always present. This should fix immediate children of input statement, but will not create containers implied by default leaves – that bit is going to be addressed by this issue.