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-694 mdsal <p>Following the discussion from the ODL forum (<a href="https://lists.opendaylight.org/g/kernel-dev/topic/86257574#555)," class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/g/kernel-dev/topic/86257574#555</a>)</p> <p>When building the <b>tapimodels</b> module in transport-pce project, the following error occurs with the tapi-notification model:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Caused by: com.google.common.base.VerifyException: Conflict on org.opendaylight.yangtools.yang.model.ri.stmt.impl.eff.RegularLeafEffectiveStatement@7e58b0f6 between LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2020-06-16)uuid, addedByUses} and LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2020-06-16)uuid, addedByUses} at com.google.common.base.Verify.verify (Verify.java:443) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:350) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:352) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.indexLeafGenerators (GeneratorReactor.java:352) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.mapToGenerator (GeneratorReactor.java:328) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.lenientResolveLeafref (GeneratorReactor.java:321) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.resolveLeafref (GeneratorReactor.java:297) at org.opendaylight.mdsal.binding.generator.impl.reactor.AbstractTypeObjectGenerator.bindTypeDefinition (AbstractTypeObjectGenerator.java:362) at org.opendaylight.mdsal.binding.generator.impl.reactor.AbstractTypeAwareGenerator.bindTypeDefinition (AbstractTypeAwareGenerator.java:53) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:399) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:401) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.bindTypeDefinition (GeneratorReactor.java:401) at org.opendaylight.mdsal.binding.generator.impl.reactor.GeneratorReactor.execute (GeneratorReactor.java:155) at org.opendaylight.mdsal.binding.generator.impl.DefaultBindingGenerator.generateFor (DefaultBindingGenerator.java:68) at org.opendaylight.mdsal.binding.generator.impl.DefaultBindingGenerator.generateTypes (DefaultBindingGenerator.java:38) at org.opendaylight.mdsal.binding.java.api.generator.JavaFileGenerator.generateFiles (JavaFileGenerator.java:74) at org.opendaylight.yangtools.yang2sources.plugin.FileGeneratorTask.execute (FileGeneratorTask.java:66) at org.opendaylight.yangtools.yang2sources.plugin.FileGeneratorTask.execute (FileGeneratorTask.java:40) at org.opendaylight.yangtools.yang2sources.plugin.GeneratorTask.execute (GeneratorTask.java:36) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources (YangToSourcesProcessor.java:335) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute (YangToSourcesProcessor.java:214) at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute (YangToSourcesMojo.java:139) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) </pre> </div></div> <p>As per the email thread, this happens with this set of models: <a href="https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/YANG" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1.1/YANG</a></p> MDSAL-694

VerifyException thrown when resolving leafrefs with TAPI models

Bug Medium Resolved Done Robert Varga Javier Errea Wed, 13 Oct 2021 15:31:34 +0000 Fri, 15 Oct 2021 18:25:35 +0000 Fri, 15 Oct 2021 05:10:39 +0000 8.0.0 8.0.5 8.0.6 Binding codegen 0 2 <p>We are violating and explicit assumption in mapToGenerator(), which is that there each EffectiveStatement has at most one Generator attached to it. This assumption happens to work for all the models we have in our platform, but TAPI seems to have a structure, where this does not hold, probably due to SchemaPath being the same, or the inheritance hierarchy this happens in.</p> <p>At any rate, this same problem is triggered with MD-SAL models if we try to bring yangtools-8.0.0-SNAPSHOT to the party, because it has been unshackled from SchemaPath (<a href="https://jira.opendaylight.org/browse/YANGTOOLS-1066" title="SchemaPath identification of SchemaNodes is costly and useless" class="issue-link" data-issue-key="YANGTOOLS-1066"><del>YANGTOOLS-1066</del></a>) and hence it is frequently the case that an EffectiveStatement object is visible in more than one part of the statement tree.</p> <p>In order to fix this, we need to eliminate indexLeafGenerators() and fix mapToGenerator() not only consider the resolved EffectiveStatement, but rather the complete state of the SchemaInferenceStack. This means taking a List&lt;EffectiveStatement&gt; and using that to navigate the Generator tree. This is easier said than done, as this navigation is not 1:1, and when looking up a Generator we need to consider not only the parent-&gt;child axis, but also the groupings and augments of an AbstractCompositeGenerator.</p> <p>The patch attached to this issue is identifying the source of badness and outlines what needs to be done to resolve it.</p> Relates MDSAL-696 YANGTOOLS-1066 Development Rank 0|i04067: