https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-193 mdsal <p>I specified default values for leafs in a model of an RPC, and the values are not being filled by the system. The model is attached. This issue is happening on master (carbon)</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-193

Default values not filled for BA RPC

Bug In Progress Unresolved Unassigned Jan Medved Mon, 22 Aug 2016 04:15:26 +0000 Thu, 17 Nov 2022 13:08:23 +0000 Binding runtime 0 3 <p>Attachment shardingsimple.yang has been added with description: Yang model where the bug can be reproduced</p> <p>Hi Jan, </p> <p>I tested the attached model in the yang parser and all default values were filled out correctly in the produced SchemaContext.</p> <p>Could you please provide more info, e.g. circumstances under which you ran into this problem or perhaps a unit test.</p> <p>Thanks</p> <p>This seems to be duplicate of <br/> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=2489" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=2489</a></p> <p>Hi Igor,</p> <p>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:</p> <p>{<br/> "shard-test": {<br/> "input": </p> { "test-type": "ROUND-ROBIN" } <p> }<br/> }</p> <p>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.</p> <p>To reproduce:</p> <p>1. check our coretutorials in the current master:</p> <p> &gt; git clone <a href="https://git.opendaylight.org/gerrit/coretutorials.git" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/coretutorials.git</a></p> <p>2. Go to the clustering/shardingsimple folder</p> <p> &gt; cd coretutorials/clustering/shardingsimple</p> <p>3. Build:<br/> &gt; mvn clean install</p> <p>4. Run the built distro:<br/> &gt; ./karaf/target/assembly/bin/karaf</p> <p>5. Point the local browser at the controller - open<br/> <a href="http://localhost:8181/index.html#/yangman/index" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8181/index.html#/yangman/index</a> (admin/admin)</p> <p>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</p> <p>After further discusion it seems it is a bug in md-sal. Hence the bug has been reopened and moved to md-sal.</p> <p>Binding Aware LazyDataObject should be filling in default nodes, we need to create a unit test in binding-dom-codec</p> <p>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.</p> <p>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.</p> <p><a href="https://jira.opendaylight.org/browse/MDSAL-303" title="Do not allow null RPC input in invocation paths" class="issue-link" data-issue-key="MDSAL-303"><del>MDSAL-303</del></a> 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.</p> Blocks MDSAL-303 Development External issue ID 6488 External issue URL Issue Type Rank 0|i02wvz: