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/MDSAL-2 mdsal <p>With following statement in yang model: </p> <p>list property {<br/> key "key";<br/> leaf key </p> { type string; } <p>}</p> <p>exception is thrown:</p> <p>java.lang.ClassCastException: org.opendaylight.yangtools.binding.generator.util.Types$ConcreteTypeImpl cannot be cast to org.opendaylight.yangtools.sal.binding.model.api.GeneratedTransferObject<br/> at org.opendaylight.yangtools.sal.java.api.generator.BuilderTemplate.generateConstructor(BuilderTemplate.java:1006)<br/> at org.opendaylight.yangtools.sal.java.api.generator.BuilderTemplate.body(BuilderTemplate.java:398)<br/> at org.opendaylight.yangtools.sal.java.api.generator.BaseTemplate.generate(BaseTemplate.java:73)<br/> at org.opendaylight.yangtools.sal.java.api.generator.BuilderGenerator.generate(BuilderGenerator.java:58)<br/> at org.opendaylight.yangtools.sal.java.api.generator.GeneratorJavaFile.generateTypeToJavaFile(GeneratorJavaFile.java:126)<br/> at org.opendaylight.yangtools.sal.java.api.generator.GeneratorJavaFile.generateToFile(GeneratorJavaFile.java:73)</p> <p>This is caused because of 2 methods with same name (getKey) are generated, first for list statement to get key, second as a getter for leaf node.</p> <p>Operating System: All<br/> Platform: PC</p> MDSAL-2

Naming conflict appears when key of list is constructed from leaf with name key

Improvement Resolved Done Robert Varga Martin Vitez Wed, 20 Nov 2013 10:35:45 +0000 Mon, 4 Jun 2018 15:45:33 +0000 Mon, 4 Jun 2018 15:45:33 +0000 Fluorine Binding codegen 0 8 <p>Solution is to rename getter getKey(), which was added by BindingGenerator<br/> to key(). Methods starting with get... should be left to be only defined by YANG.</p> <p>This is API breakage, so it needs to be part of binding specification v2.</p> <p>Working on it</p> <p>status changed</p> <p>According to RFC 6020 name of concrete container, leaf, leaf-list, list,<br/> grouping, choice ... has to start with letter which is followed with<br/> letters, digits, '_', '-', or '.' character.</p> <p>Before this commit there was generated for key of a list getter method<br/> 'getKey'. 'key' word was used while getter method was constructed.<br/> In this commit 'key$' word is used. Dollar is character which can't be used in<br/> YANG but can be used in JAVA. Therefore it can't happen that list<br/> subelement identifier will be also 'key$'.</p> <p>As was specified in bugzilla - interface (from YANG list) and implementing<br/> class are generated with 'key()' getter method and with member field '_key$'.<br/> Builder for implementing class is generated with member field<br/> '_key$' and with 'keyGet()' and 'keySet()' getter and setter methods.</p> <p>Name conflict for methods 'key()', 'keySet()', 'keyGet()' is solved<br/> because all methods generated from subelements of YANG list starts with<br/> 'get', 'set' or 'is'.</p> <p>Currently all yangtools projects were succesfuly built with this change. The commit is in draft state<br/> <a href="https://git.opendaylight.org/gerrit/#/c/5521/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/5521/</a></p> <p>test if methods 'get()', 'keyGet()', 'keySet()' are in builder, interface and interface implementation was added</p> <p>The change was rebased on 30APR2014</p> <p>There are much more flavors of this error:<br/> The problem basically always occurs, when a list has a child object named "key". So I've found a case, where a list contains a container called key which causes basically the same issue.</p> <p>In general I would agree, that renaming the method "getKey()" to something else like "whatKey()" would fix that issue. I am only concerned about the ongoing discussion, that getKey() might still be available for compatibility with existing "yang binding v1" integration projects - and it gets only removed in cases where naming conflicts occur. If going down that path, implementation should be smart enough, to not only check for leaves called "key" but other types like container or list as well.</p> <p>I am surprised that this is categorized as with importance "lowest" and "enhancement". The thing is basically, that this break with existing vendor YANG models - as key is very likely used as YANG variable name around protocol authentication and privacy (for example BGP keychains, IPsec, ...). In my eyes this is not just a corner case - it is a bug with major severity, beside we come to such conclusion that ODL should not be flexible enough to compile any valid/existing YANG model in the market.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/53279/10" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53279/10</a></p> <p>Fluorine Binding V1 is cleared for this API breakage. Builders will use 'withKey()' instead of 'setKey()'. This also affects augmentations, where we need to just solve 'getAugmentation()', renaming it to 'augmentation()'.</p> Duplicate MDSAL-159 YANGTOOLS-357 Relates MDSAL-244 TSC-101 Development External issue ID 157 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i02vpj: