Operating System: All
Platform: All

Attachment karaf.log.gz has been added with description: karaf log

Possibly yangtools/mdsal bug - problem addresses via email - https://lists.opendaylight.org/pipermail/yangtools-dev/2016-August/001549.html

A temporary workaround should be possible in BGP code.

master: https://git.opendaylight.org/gerrit/44875

https://git.opendaylight.org/gerrit/#/c/44875/1
Attempted fix in Yangtools shows another exception:

2016-08-31 10:08:47,083 | ERROR | on-dispatcher-65 | DataTreeChangeListenerActor | 200 - org.opendaylight.controller.sal-distributed-datastore - 1.5.0.SNAPSHOT | Error notifying listener org.opendaylight.controller.md.sal.binding.impl.BindingClusteredDOMDataTreeChangeListenerAdapter@69f546e2
java.lang.ClassCastException: com.sun.proxy.$Proxy210 cannot be cast to org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.openconfig.extensions.rev160614.AfiSafi2
at org.opendaylight.protocol.bgp.openconfig.impl.BGPOpenConfigMappingServiceImpl.toAddPathCapability(BGPOpenConfigMappingServiceImpl.java:125)[334:org.opendaylight.bgpcep.bgp-openconfig-impl:0.7.0.SNAPSHOT]
at Proxy580841b1_fd76_4386_a70a_c33a64826007.toAddPathCapability(Unknown Source)[:]
at Proxydb312b39_aa4c_4eac_bc86_1129d5460378.toAddPathCapability(Unknown Source)[:]
at org.opendaylight.protocol.bgp.rib.impl.config.BgpPeer.getBgpParameters(BgpPeer.java:141)[307:org.opendaylight.bgpcep.bgp-rib-impl:0.7.0.SNAPSHOT]

> another exception

Well, it is basically the same one.

There are two augmentations in play here, AfiSafi1 and AfiSafi2, which are really completely equivalent, as they end up targeting instantiations of the same grouping:

package org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.bgp.openconfig.extensions.rev160614;
import org.opendaylight.yangtools.yang.binding.Augmentation;
import org.opendaylight.yangtools.yang.binding.DataObject;
import org.opendaylight.yang.gen.v1.http.openconfig.net.yang.bgp.rev151009.BgpNeighborAddPathsConfig;
import org.opendaylight.yang.gen.v1.http.openconfig.net.yang.bgp.multiprotocol.rev151009.bgp.common.afi.safi.list.AfiSafi;

public interface AfiSafi1
extends
DataObject,
Augmentation<AfiSafi>,
BgpNeighborAddPathsConfig

AfiSafi2 looks exactly the same. Note that we are looking for AfiSafi2 here. Based on the model (bgp-openconfig-extensions) and the call trace, we should be looking up AfiSafi1 (as that augments neighbor, AfiSafi2 augments global). This is something yangtools probably confused and should be rectified by the proposed patch.

Now when DTCL is being invoked, we go through LazyDataObject and since we have not touched getAugmentations(), but are targeting a single one, we end up calling through DataObjectCodecContext.streamChild() and after some mucking around in augmentationByClassOrEquivalentClass().

We then proceed to scan all real augmentations and check if any of them are equivalent using BindingReflections.isSubstitutionFor() – which returns true, as the classes are really equivalent. Hence we instantiate a proxy for AfiSafi1, thinking it is a valid replacement for AfiSafi2 and return that – leading to ClassCastException.

So aside from bgpcep fix, https://git.opendaylight.org/gerrit/44961, which should rectify the lookup and ClassCastException, we need to solve the problem in mdsal. I can think of two avenues:

• teach BindingReflections to detect this problem (though it is not clear what check can be done at the class level).
• teach code generator to not emit both AfiSafi1 and AfiSafi2 – they can be safely squashed since their targets are already squashed by the binding spec

I think we should implement the second option, as it lowers the number of classes and prevents this sort of confusion.

The ClassCastException has disappeared, but the confusion about AfiSafi1/AfiSafi2 needs to be cleaned up in MD-SAL. Reducing severity and dropping target release.

> the confusion about AfiSafi1/AfiSafi2 needs to be cleaned up in MD-SAL

Do we have a unit test proving the confusion has been cleaned up indeed (or another Bug tracking it if not)?

Of course we do. MDSAL-328.

Oh, Now I see the fix: https://git.opendaylight.org/gerrit/72961

It seems that in order for Jira to show the link to a related Change, the issue name has to be written in the first line of the commit message.

> in order for Jira to show the link to a related Change

And now I see the gerrit links in MDSAL-328.
Not sure why I did not see them before, I recall the link to related Openflowplugin bug...