Hello everyone, we are still ways off of having a smooth transition plan from Binding V1 to Binding V2 and a large body of models are getting standardized, some of which trigger V1 deficiencies.
Contingent on favorable outcome of the discussion here: https://lists.opendaylight.org/pipermail/mdsal-dev/2018-March/001517.html, it would be possible to fix majority of these with very few changes, which will break pretty much everyone out there, but is ways that are: - obvious compilation breakages - can be fixed mechanically Specifically I mean the following changes (warning, technical details ahead): 1) Map identity statements to interfaces, not abstract classes RFC6020 specified single inheritance for identities, which meant mapping them to abstract classes worked as expected. RFC7950 changed the underlying meta model and allowed identities to have multiple base statements -- leading to multiple inheritance. Java does not support multiple inheritance of state, hence we currently cannot represent this YANG 1.1 construct in generated code. The change from abstract class to interface is fully source-compatible for all use cases that are supported. Invalid uses (like subclassing a generated identity) will break and will require a mechanical source code update. 2) Replace org.opendaylight.yangtools.yang.binding.Identifiable.getKey() This is the most major pain in models, as the name chosen clashes with the namespace used by generated code for getters. This means any construct like: list foo { key ...; leaf key { ... } } leads either to a codegen failure on ClassCastException or results in code which cannot be compiled. The solution is to rename getKey() to key(). As all user-governed names in generated code is prefixed (with "is", "get" and similar), this will permanently solve this particular problem. Unfortunately it will also break all code which deals with getting/putting elements into keyed lists. The fix is a mechanical one and probably scriptable (but I am not much for writing scripts). 3) Change the signature of generated RPC invocation methods This change has two facets, the first of which is convenience to callers of RPCs: these are currently defined as returning a java.util.concurrent.Future. The MD-SAL core implementation and all RPC implementations are using subclasses of ListenableFuture while asynchronous end users tend to JdkFutureAdapters or straightout casts to change the Future into a ListenableFuture. The other facet is the request and response type when the RPC declaration in YANG does not have an input or output statement: rpc foo { }; rpc bar { input { } }; rpc bar { output { } }; Such RPCs are mapped to either not having an input argument or returning a Future<Void>. This is a design mistake, as YANG specification calls for input/output statements to be implicitly present -- they are valid targets for "augment" statement irrespective of whether they were explicitly declared. While we can compile such models, all of the information in such augmentations is inaccessible to Binding users, as there is no anchor representation class generated for input/output statements. I propose this to be fixed three changes: a) always generate Input/Output statements for RPCs b) always take an Input as the argument of generated method c) always return ListenableFuture<Output> from generated method The first one is completely compatible, we just end up generating otherwise useless classes. The second one will break both callers and implementations of RPCs which do not have an input statement in the model. The fix is a mechanical one, it is fair to send an empty Input and ignore the result. Current trouble spots can be fixed ahead of time by explicitly changing the model, which will incur exactly same amount of breakage. The third one will break implementations which do not specify ListenableFuture as their overridden return type or which do not return a subclass of ListenableFuture. The fix is largely a mechanical one. These changes would be delivered as three separate code drops, the order being 1, 2, 3. The last code drop would happen before the mid-way checkpoint in the Fluorine release cycle. Are there any objections to MD-SAL incorporating these changes? Thanks, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
