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/YANGTOOLS-1443 yangtools <p>Creating EffectiveModelContext with DefaultYangParserFactory fails if any models use `yang-data` extension from ietf-restconf.yang. This issue could be related to ietf-restconf namespace "urn:ietf:params:xml:ns:yang:ietf-restconf", because if is changed EffectiveModelContext is successfully built.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[main] WARN org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext - Unexpected error processing source RevisionSourceIdentifier [name=test-bug@2017-07-27]. Please file an issue with this model attached. java.util.NoSuchElementException: No value present     at java.base/java.util.Optional.get(Optional.java:148)     at org.opendaylight.yangtools.rfc8040.parser.YangDataEffectiveStatementImpl.&lt;init&gt;(YangDataEffectiveStatementImpl.java:40)     at org.opendaylight.yangtools.rfc8040.parser.YangDataStatementSupport.createEffective(YangDataStatementSupport.java:123)     at org.opendaylight.yangtools.rfc8040.parser.YangDataStatementSupport.createEffective(YangDataStatementSupport.java:36)     at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.createEffective(AbstractStatementSupport.java:85)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:124)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:109)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.createEffective(StatementContextBase.java:439)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.loadEffective(ReactorStmtCtx.java:389)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.buildEffective(ReactorStmtCtx.java:385)     at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)     at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)     at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)     at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)     at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)     at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)     at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)     at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.buildEffectiveSubstatements(AbstractStatementSupport.java:139)     at org.opendaylight.yangtools.yang.parser.rfc7950.stmt.module.ModuleStatementSupport.buildEffectiveSubstatements(ModuleStatementSupport.java:227)     at org.opendaylight.yangtools.yang.parser.spi.meta.AbstractStatementSupport.createEffective(AbstractStatementSupport.java:83)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:124)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.AbstractResumedStatement.createEffective(AbstractResumedStatement.java:109)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementContextBase.createEffective(StatementContextBase.java:439)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.loadEffective(ReactorStmtCtx.java:389)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.ReactorStmtCtx.buildEffective(ReactorStmtCtx.java:385)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.transformEffective(BuildGlobalContext.java:261)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.buildEffective(BuildGlobalContext.java:211)     at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:224)     at org.opendaylight.yangtools.yang.parser.impl.DefaultYangParser.buildEffectiveModel(DefaultYangParser.java:96) </pre> </div></div> <p> </p> YANGTOOLS-1443

Fix YangDataEffectiveStatement definition

Bug High Resolved Done Robert Varga Peter Suna pt Thu, 26 May 2022 10:43:33 +0000 Wed, 12 Oct 2022 18:19:38 +0000 Wed, 12 Oct 2022 18:19:38 +0000 9.0.0 8.0.6 7.0.17 10.0.0 9.0.2 8.0.8 parser 0 2 <p>What is the real-world example of this failure?<br/> The 'anydata' example is invalid AFAICT, based on rc:yang-data's description:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> It MUST contain data definition statements that result in exactly one container data node definition. An instance of a YANG data template can thus be translated into an XML instance document, whose top-level element corresponds to the top-level container. </pre> </div></div> <p>Yes, I found this inside yumaworks netconf-pro server. So if the model is invalid, why it works when I change namespace inside extension-model to "extension:model" or any other?</p> <p>Simple: if you do that, then suddenly it no longer is "The RFC8040 yang-data Extension", but some random extension we know nothing about. RFC7950 Section 6.3.1 applies:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> The processing of extensions depends on whether support for those extensions is claimed for a given YANG parser or the tool set in which it is embedded. An unsupported extension appearing in a YANG module as an unknown-statement (see Section 14) MAY be ignored in its entirety. Any supported extension MUST be processed in accordance with the specification governing that extension. </pre> </div></div> <p>It seems the spec is rather bad and based on <a href="https://mailarchive.ietf.org/arch/msg/netconf/PxCbSq6rp5Sj0C2ylhzqeQrH2vo/" class="external-link" target="_blank" rel="nofollow noopener">this NETCONF WG thread</a> the intent is that "container data node definition" be <b>NOT</b> interpreted with RFC7950 terminology. Specifically it seems that "container" is meant to say "interior node with a single instance", i.e. include anydata and anyxml and perhaps even single-element lists.</p> Development Rank 0|i042gv: