[YANGTOOLS-1060] SchemaContextUtil fails to resolve submodule-only prefixes Created: 16/Dec/19  Updated: 30/Dec/19  Resolved: 30/Dec/19

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: 3.0.7, 4.0.4
Fix Version/s: 3.0.8, 4.0.5

Type: Bug Priority: Medium
Reporter: Miroslav Kovac Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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.

The unit test results in:

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.153 s <<< FAILURE! - in org.opendaylight.mdsal.binding.generator.impl.Mdsal499Test
[ERROR] testSubmoduleImport(org.opendaylight.mdsal.binding.generator.impl.Mdsal499Test)  Time elapsed: 0.153 s  <<< ERROR!
java.lang.IllegalArgumentException: Failed to resolve xpath: no module found for 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.<init>(AbstractTypeGenerator.java:205)
	at org.opendaylight.mdsal.binding.generator.impl.CodegenTypeGenerator.<init>(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)


 Comments   
Comment by Miroslav Kovac [ 17/Dec/19 ]

This seemes to be more of a yangtools problem creating wrong schemaContext. I think this should be moved under yangtools project...

Comment by Robert Varga [ 28/Dec/19 ]

Probably, but it needs a bit of analysis first

Comment by Robert Varga [ 28/Dec/19 ]

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.--

Comment by Robert Varga [ 29/Dec/19 ]

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.

Generated at Wed Feb 07 20:55:04 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.