Operating System: All
Platform: PC

Solution is to rename getter getKey(), which was added by BindingGenerator
to key(). Methods starting with get... should be left to be only defined by YANG.

This is API breakage, so it needs to be part of binding specification v2.

Working on it

status changed

According to RFC 6020 name of concrete container, leaf, leaf-list, list,
grouping, choice ... has to start with letter which is followed with
letters, digits, '_', '-', or '.' character.

Before this commit there was generated for key of a list getter method
'getKey'. 'key' word was used while getter method was constructed.
In this commit 'key$' word is used. Dollar is character which can't be used in
YANG but can be used in JAVA. Therefore it can't happen that list
subelement identifier will be also 'key$'.

As was specified in bugzilla - interface (from YANG list) and implementing
class are generated with 'key()' getter method and with member field '_key$'.
Builder for implementing class is generated with member field
'_key$' and with 'keyGet()' and 'keySet()' getter and setter methods.

Name conflict for methods 'key()', 'keySet()', 'keyGet()' is solved
because all methods generated from subelements of YANG list starts with
'get', 'set' or 'is'.

Currently all yangtools projects were succesfuly built with this change. The commit is in draft state
https://git.opendaylight.org/gerrit/#/c/5521/

test if methods 'get()', 'keyGet()', 'keySet()' are in builder, interface and interface implementation was added

The change was rebased on 30APR2014

There are much more flavors of this error:
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.

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.

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.

https://git.opendaylight.org/gerrit/#/c/53279/10

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()'.