[MDSAL-182] Java binding v1: leafref up two containers not found if from grouping Created: 01/Jul/16  Updated: 27/May/19  Resolved: 21/Mar/19

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: 4.0.0, Fluorine SR3, 3.0.7

Type: Bug
Reporter: Vratko Polak Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
blocks MDSAL-426 Specialize relative leafref types dur... Resolved
Duplicate
is duplicated by MDSAL-113 Java Binding: groupings should not sh... Resolved
is duplicated by MDSAL-188 Can't resolve leafref when its path i... Resolved
is duplicated by MDSAL-423 Failed to find leafref target Resolved
External issue ID: 6141

 Description   

This may be a Yangtools bug, but the exception below comes from binding generator.

Example models: https://git.opendaylight.org/gerrit/#/c/41142/2

They shows that if leafref is only up one level, or is not from grouping, then everything works. This is what happens in the $summary case:

 

[ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.yangtools.maven.sal.api.gen.plugin.CodeGeneratorImpl generator
 java.lang.IllegalArgumentException: Failed to find leafref target: ../../../target-leaf in module grouping-leafref (QNameModule{ns=odl:test:leafref:grouping, rev=2016-07-01})
 at com.google.common.base.Preconditions.checkArgument(Preconditions.java:145)
 at org.opendaylight.yangtools.sal.binding.yang.types.TypeProviderImpl.provideTypeForLeafref(Typ
 eProviderImpl.java:496)
 at org.opendaylight.yangtools.sal.binding.yang.types.TypeProviderImpl.javaTypeForLeafrefOrIdent
 ityRef(TypeProviderImpl.java:318)
 at org.opendaylight.yangtools.sal.binding.yang.types.TypeProviderImpl.javaTypeForSchemaDefiniti
 onType(TypeProviderImpl.java:211)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.resolveLeafSchemaNodeAsMethod(BindingGeneratorImpl.java:1452)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.addSchemaNodeToBuilderAsMethod(BindingGeneratorImpl.java:1143)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.resolveDataSchemaNodes(BindingGeneratorImpl.java:1080)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.groupingToGenType(BindingGeneratorImpl.java:726)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.groupingsToGenTypes(BindingGeneratorImpl.java:703)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.moduleToGenTypes(BindingGeneratorImpl.java:281)
 at org.opendaylight.yangtools.sal.binding.generator.impl.BindingGeneratorImpl.generateTypes(BindingGeneratorImpl.java:259)
 at org.opendaylight.yangtools.maven.sal.api.gen.plugin.CodeGeneratorImpl.generateSources(CodeGeneratorImpl.java:61)
 at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSourcesWithOneGenerator(YangToSourcesProcessor.java:348)
 at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.generateSources(YangToSourcesProcessor.java:293)
 at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.execute(YangToSourcesProcessor.java:95)
 at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.conditionalExecute(YangToSourcesProcessor.java:104)
 at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute(YangToSourcesMojo.java:119)
 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

 

 Comments   
Comment by Martin Ciglan [ 06/Mar/17 ]

Hi Alexis

Since we are focusing now on Carbon release, I'm moving this Binding spec v1 bug to Boron-4. Please let me know whether this is not an big issue for you. Thanks.

Martin

Comment by Dhruv Bhardwaj [ 04/Dec/18 ]

Hi,

Is there are a  fix scheduled for this ? we are facing issues with importing openconfig models into our project.

ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl generator

java.lang.IllegalArgumentException: Failed to find leafref target: ../../../../../../../sensor-groups/sensor-group/config/sensor-group-id in module openconfig-telemetry (QNameModule

{ns=[http://openconfig.net/yang/telemetry|https://urldefense.proofpoint.com/v2/url?u=http-3A__openconfig.net_yang_telemetry&d=DwQGaQ&c=09aR81AqZjK9FqV5BSCPBw&r=fYBUIQyrd8QW3g0UM4Qde3P2Hew0bssk8DkR23Im7yo&m=cUAc870bkga6sUyXGyvIF3RRJHIBgj4KMNwPZcDH3QQ&s=zLnJIt80-HJTgc_wkmPcmihmAdiSdD_Z6Ol8S1GrjwE&e=], rev=2017-08-24}

)

                at com.google.common.base.Preconditions.checkArgument(Preconditions.java:455)

 

Comment by Robert Varga [ 17/Mar/19 ]

The problem here seems to be that we are dealing with a grouping-based typedef, which points outside of the grouping.

Given that we are not dealing with a concrete instantiation, we just don't know where it points to, as per https://tools.ietf.org/html/rfc7950#section-9.9.2 . The typedef in grouping needs to resolve to a plain Object, and be concretized in instantiations.

It is a mystery (for now) how this ends up working for the other cases.

Comment by Robert Varga [ 17/Mar/19 ]

Sorry for the long delay, what exactly is the model set you are seeing the issue with?

 

Comment by Dhruv Bhardwaj [ 18/Mar/19 ]

Hi Robert, Thanks for your response.

we are facing issues with openconfig-telemetry.yang https://github.com/OpenROADM/OpenROADM_MSA_Public/blob/master/model/Device/openconfig-telemetry.yang

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