[MDSAL-531] Unable to resolve grouping Created: 11/Mar/20 Updated: 18/May/21 Resolved: 18/May/21 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding codegen |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0 |
| Type: | Bug | Priority: | Medium |
| Reporter: | Miroslav Kovac | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
the following two modules:
module a {
yang-version 1.1;
namespace "a";
prefix a;
import b { prefix b;}
grouping foo {
container bar {
leaf foo {
type string;
}
uses software-operation-state;
}
grouping software-operation-state {
leaf bar2 {
type empty;
}
uses next-operation-group;
}
grouping next-operation-group {
list next-operation {
key order;
config false;
leaf order {
description "A logical sequence number of operations to be done.";
type uint8;
}
leaf operation-type {
description "Type of software action launched on the device.";
type string;
}
leaf software-name {
description "Name of the software on which the operation was performed. For download operations, the leaf only records the software name and not the complete URL.";
type string;
}
} // list next-operation
}
}
augment "/b:fooo" {
uses a:foo;
}
}
module b {
yang-version 1.1;
namespace "b";
prefix b;
container fooo {
leaf baar {
type empty;
}
}
}
results in AbstractTypeGenerator.addImplementedInterfaceFromUses() failure: [ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl generator
java.lang.IllegalStateException: Grouping AbsoluteSchemaPath{path=[(a)foo, (a)next-operation-group]}is not resolved for SoftwareOperationState
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addImplementedInterfaceFromUses (AbstractTypeGenerator.java:1887)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1625)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1593)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1587)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.groupingsToGenTypes (AbstractTypeGenerator.java:700)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1624)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addDefaultInterfaceDefinition (AbstractTypeGenerator.java:1593)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.processDataSchemaNode (AbstractTypeGenerator.java:281)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.containerToGenType (AbstractTypeGenerator.java:299)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.addSchemaNodeToBuilderAsMethod (AbstractTypeGenerator.java:1055)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.resolveDataSchemaNodes (AbstractTypeGenerator.java:1004)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.moduleToGenTypes (AbstractTypeGenerator.java:239)
at org.opendaylight.mdsal.binding.generator.impl.AbstractTypeGenerator.<init> (AbstractTypeGenerator.java:200)
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.maven.api.gen.plugin.CodeGeneratorImpl.generateSources (CodeGeneratorImpl.java:70)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSourcesWithOneGenerator (YangToSourcesProcessor.java:383)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources (YangToSourcesProcessor.java:332)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute (YangToSourcesProcessor.java:159)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute (YangToSourcesMojo.java:127)
|
| Comments |
| Comment by Miroslav Kovac [ 11/Mar/20 ] |
|
weird thing is that if we are not augmenting and we do following changes in module a:
augment "/b:fooo" {
uses a:foo;
}
changed to
container fooo {
uses a:foo;
}
So we do not need module b anymore. The generator does not have problem. And even more weird same goes if we keep augmentation but we augment the same container in same model. So again we do not need module b and the module a would change like this:
augment "/b:fooo" {
uses a:foo;
}
changed to
augment "/a:fooo" {
uses a:foo;
}
container fooo {
leaf foo_leaf {
type empty;
}
}
|
| Comment by Robert Varga [ 11/Apr/20 ] |
|
Version 6.0.0 is not affected as we do not need to resolve the path – we have the grouping readily available. |
| Comment by Robert Varga [ 17/Apr/20 ] |
|
Right, and the problem seems to come from GroupingDependencySort – it is failing to reorder a:foo's grouping according to their dependencies, generating them in the declaration order. This means next-operation-group is not processed yet and hence its type does not exist yet. |
| Comment by Robert Varga [ 17/Apr/20 ] |
|
So a workaround would be to reverse the order of definition of these two. |
| Comment by Robert Varga [ 17/Apr/20 ] |
|
The sorting problem boils down to the two groupings being instantiated, i.e. having paths of:
AbsoluteSchemaPath{path=[(b)fooo, (a)software-operation-state]}
AbsoluteSchemaPath{path=[(b)fooo, (a)next-operation-group]}
and the uses statement is pointing to original grouping:
UsesEffectiveStatementImpl[groupingPath=AbsoluteSchemaPath{path=[(a)foo, (a)next-operation-group]}]
So we end up not realizing that there is a dependency, as the pointer is all wrong.
|