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-668 mdsal <p>In TransportPCE, we have encountered an issue since Silicon with the implementation of org-openroadm-device@2020-05-29.yang model.<br/> The problem is located in line 1300:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>leaf-list port-list { type leafref { path "/org-openroadm-device/circuit-packs[circuit-pack-name=current()/../circuit-pack-name]/ports/port-name"; } description "port list"; } } </pre> </div></div> <p> </p> <p>The List&lt;?&gt; type of port-list, generated during compilation of the model, seems not being taken into account during serialization step and throws an IllegalStateException:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Caused by: java.lang.IllegalStateException: Unexpected return type ? at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext.getLeafNodesUsingReflection(BindingCodecContext.java:386) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext.getLeafNodes(BindingCodecContext.java:355) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataObjectCodecContext.&lt;init&gt;(DataObjectCodecContext.java:102) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.ListNodeCodecContext.&lt;init&gt;(ListNodeCodecContext.java:28) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.KeyedListNodeCodecContext.&lt;init&gt;(KeyedListNodeCodecContext.java:54) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.KeyedListNodeCodecContext$Unordered.&lt;init&gt;(KeyedListNodeCodecContext.java:41) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.KeyedListNodeCodecContext.create(KeyedListNodeCodecContext.java:71) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataContainerCodecPrototype.createInstance(DataContainerCodecPrototype.java:237) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataContainerCodecPrototype.loadInstance(DataContainerCodecPrototype.java:224) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataContainerCodecPrototype.get(DataContainerCodecPrototype.java:220) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataObjectCodecContext.streamChild(DataObjectCodecContext.java:195) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.CodecDataObject.codecMember(CodecDataObject.java:81) ~[?:?] at org.opendaylight.yang.gen.v1.http.org.openroadm.device.rev200529.circuit.pack.Ports$$$codecImpl.getSupportingPortList(Unknown Source) ~[?:?] at org.opendaylight.yang.gen.v1.http.org.openroadm.device.rev200529.circuit.pack.Ports$$$streamer.serialize(Unknown Source) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataObjectStreamer.commonStreamList(DataObjectStreamer.java:153) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.DataObjectStreamer.streamMap(DataObjectStreamer.java:133) ~[?:?] at org.opendaylight.yang.gen.v1.http.org.openroadm.device.rev200529.circuit.packs.CircuitPacks$$$streamer.serialize(Unknown Source) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext$DataObjectSerializerProxy.serialize(BindingCodecContext.java:121) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.impl.BindingCodecContext.toNormalizedNode(BindingCodecContext.java:506) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.spi.ForwardingBindingDOMCodecServices.toNormalizedNode(ForwardingBindingDOMCodecServices.java:66) ~[?:?] at org.opendaylight.mdsal.binding.dom.codec.spi.ForwardingBindingDOMCodecServices.toNormalizedNode(ForwardingBindingDOMCodecServices.java:66) ~[?:?] at org.opendaylight.mdsal.binding.dom.adapter.BindingDOMWriteTransactionAdapter.toNormalized(BindingDOMWriteTransactionAdapter.java:107) ~[?:?] at org.opendaylight.mdsal.binding.dom.adapter.BindingDOMWriteTransactionAdapter.toNormalized(BindingDOMWriteTransactionAdapter.java:100) ~[?:?] at org.opendaylight.mdsal.binding.dom.adapter.BindingDOMWriteTransactionAdapter.merge(BindingDOMWriteTransactionAdapter.java:50) ~[?:?] at org.opendaylight.transportpce.common.device.DeviceTransaction.merge(DeviceTransaction.java:66) ~[?:?] at org.opendaylight.transportpce.common.openroadminterfaces.OpenRoadmInterfacesImpl710.postEquipmentState(OpenRoadmInterfacesImpl710.java:225) ~[?:?] at org.opendaylight.transportpce.common.openroadminterfaces.OpenRoadmInterfacesImpl.postEquipmentState(OpenRoadmInterfacesImpl.java:127) ~[?:?]</pre> </div></div> MDSAL-668

Issue serializing object type defined by a leafref

Bug Medium Resolved Done Robert Varga Gilles Thouenon Tue, 15 Jun 2021 16:12:50 +0000 Wed, 16 Jun 2021 14:21:14 +0000 Wed, 16 Jun 2021 14:21:14 +0000 8.0.0 7.0.8 Binding runtime 0 3 <p>The ISE is caused by our inability to deal with WildcardType, from whence we should be taking the upper bound – but that will typically not exist, so we'd circle to Object.class and defer to NOOP codec – which is what we have historically done.</p> <p>While that would happen to work for the concrete case at hand, it is the incorrect thing to do in general.</p> <p>The List could contain InstanceIdentifier (which needs to be translated to YangInstanceIdentifiers), j.l.Class (which needs to be translated to QNames), or various generated TypeObject subclasses (which need to be decapsulated/translated).</p> <p>At the end of the day, the current approach to codec lookup is inadequate, as the codec link cannot always be accurately ascertained by pure reflection. This, by the way, also affect leaf nodes, but is hidden by the fact we return an Object and (again) default to NOOP codec.</p> <p>This case can only happen when the leafref target cannot be resolved, which means the binding construct is somewhere inside a grouping and therefore we are (again) dealing with an ambiguity coming from not operating on instantiated context – i.e. the construct at hand <b>could</b> end up being interpreted as List&lt;InstanceIdentifier&gt; or List&lt;String&gt; in two different instantiations of the grouping where it is defined.</p> <p>There are multiple difficulties here:</p> <ol> <li>establishing instantiation cardinality of the grouping at hand. There can be 0, 1, or more instantiations. For 0 instantiations we should not be hitting this case anyway and we should never be calling on this codec (because there is no NormalizedNode manifestation). For one instantiation, we can use type information from that instantiation and inline it in the grouping scope – and use a static codec just as we do in other cases.</li> <li>for multiple instantiations we need to determine what the possible typing instantiation is. If we can prove it is always the same type, we can again hoist as in the case of a single instantiation. For multiple resulting types we need to have polymorphic codec, which is somehow specialized for each possible instantiation.</li> <li>we also need to deal with the first two in a scalable manner, which hopefully does not force us outside of our well-trodded lazy initialization mode of operation. That probably requires communicating (on-demand?) instantiation information along the $$$streamer/$$$codecImpl chain.</li> </ol> <p>The good news is that if we can determine cardinatility to be 1, we can also use the currently-unused CodecDataObjectGenerator.Fixed, which offers runtime performance benefits, as noted in <a href="https://jira.opendaylight.org/browse/MDSAL-443" title="Inline CodecDataObject&#39;s NodeContextSuppliers" class="issue-link" data-issue-key="MDSAL-443">MDSAL-443</a>.</p> <p>So the ISE is in scope of this issue. Correction of codec lookup is part of <a href="https://jira.opendaylight.org/browse/MDSAL-670" title="BindingCodecContext does not deal with unresolved leafrefs" class="issue-link" data-issue-key="MDSAL-670">MDSAL-670</a>, which will be done separately.</p> Issue split MDSAL-670 MDSAL-669 Development Rank 0|i03ycv: