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-1060 yangtools <p>If the submodule contains import with prefix and this prefix is used in extension or path substatement but this import is not in its parent module as well source generation will fail with with no module found for prefix. Interestingly this does not apply for uses or types.</p> <p>The unit test results in:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.153 s &lt;&lt;&lt; FAILURE! - in org.opendaylight.mdsal.binding.generator.impl.Mdsal499Test [ERROR] testSubmoduleImport(org.opendaylight.mdsal.binding.generator.impl.Mdsal499Test) Time elapsed: 0.153 s &lt;&lt;&lt; ERROR! java.lang.IllegalArgumentException: Failed to resolve xpath: no module found <span class="code-keyword">for</span> prefix imp in module parent at com.google.common.base.Preconditions.checkArgument(Preconditions.java:441) at org.opendaylight.yangtools.yang.model.util.SchemaContextUtil.stringPathPartToQName(SchemaContextUtil.java:542) at org.opendaylight.yangtools.yang.model.util.SchemaContextUtil.xpathToQNamePath(SchemaContextUtil.java:513) at org.opendaylight.yangtools.yang.model.util.SchemaContextUtil.findDataSchemaNode(SchemaContextUtil.java:143) at org.opendaylight.mdsal.binding.yang.types.AbstractTypeProvider.isLeafRefSelfReference(AbstractTypeProvider.java:284) at org.opendaylight.mdsal.binding.yang.types.AbstractTypeProvider.javaTypeForLeafrefOrIdentityRef(AbstractTypeProvider.java:300) at org.opendaylight.mdsal.binding.yang.types.AbstractTypeProvider.javaTypeForSchemaDefinitionType(AbstractTypeProvider.java:196) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.resolveLeafSchemaNodeAsMethod(AbstractTypeGenerator.java:1404) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addSchemaNodeToBuilderAsMethod(AbstractTypeGenerator.java:1105) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.resolveDataSchemaNodes(AbstractTypeGenerator.java:1058) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.containerToGenType(AbstractTypeGenerator.java:307) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addSchemaNodeToBuilderAsMethod(AbstractTypeGenerator.java:1109) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.resolveDataSchemaNodes(AbstractTypeGenerator.java:1058) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.moduleToGenTypes(AbstractTypeGenerator.java:244) at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.&lt;init&gt;(AbstractTypeGenerator.java:205) at org.opendaylight.mdsal.binding.generator.impl.CodegenTypeGenerator.&lt;init&gt;(CodegenTypeGenerator.java:32) at org.opendaylight.mdsal.binding.generator.impl.BindingGeneratorImpl.generateTypes(BindingGeneratorImpl.java:64) at org.opendaylight.mdsal.binding.generator.api.BindingGenerator.generateTypes(BindingGenerator.java:30) at org.opendaylight.mdsal.binding.generator.impl.Mdsal499Test.testSubmoduleImport(Mdsal499Test.java:25) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418) </pre> </div></div> YANGTOOLS-1060

SchemaContextUtil fails to resolve submodule-only prefixes

Bug Medium Resolved Done Robert Varga Miroslav Kovac Mon, 16 Dec 2019 14:37:40 +0000 Mon, 30 Dec 2019 21:55:53 +0000 Mon, 30 Dec 2019 21:55:53 +0000 3.0.7 4.0.4 3.0.8 4.0.5 0 2 <p>This seemes to be more of a yangtools problem creating wrong schemaContext. I think this should be moved under yangtools project...</p> <p>Probably, but it needs a bit of analysis first</p> <p>So the problem is that SchemaContextUtil.findDataSchemaNode() cannot find the imported prefix, which is not known in the Module passed in by MD-SAL. Correct import actually exists in the submodule and Submodule extends Module – hence MD-SAL could pass in the correct Submodule and things would work just fine. The problem with that approach is that MD-SAL would have to go fishing for the right submodule – which is clearly wrong.--</p> <p>For yangtools-{3,4}.0.x this ends up being rather simple – the path in question is absolute and has prefixes – hence in reality the PathExpression already contains the QNames in resolved form and we only need to teach SchemaContextUtil.findDataSchemaNode() to use it.</p> Development Rank 0|i03qdb: