Issue serializing object type defined by a leafref

So the ISE is in scope of this issue. Correction of codec lookup is part of , which will be done separately.

This case can only happen when the leafref target cannot be resolved, which means the binding construct is somewhere inside a grouping and therefore we are (again) dealing with an ambiguity coming from not operating on instantiated context – i.e. the construct at hand could end up being interpreted as List<InstanceIdentifier> or List<String> in two different instantiations of the grouping where it is defined.

There are multiple difficulties here:

1. establishing instantiation cardinality of the grouping at hand. There can be 0, 1, or more instantiations. For 0 instantiations we should not be hitting this case anyway and we should never be calling on this codec (because there is no NormalizedNode manifestation). For one instantiation, we can use type information from that instantiation and inline it in the grouping scope – and use a static codec just as we do in other cases.

2. for multiple instantiations we need to determine what the possible typing instantiation is. If we can prove it is always the same type, we can again hoist as in the case of a single instantiation. For multiple resulting types we need to have polymorphic codec, which is somehow specialized for each possible instantiation.

3. we also need to deal with the first two in a scalable manner, which hopefully does not force us outside of our well-trodded lazy initialization mode of operation. That probably requires communicating (on-demand?) instantiation information along the $$$streamer/$$$codecImpl chain.

The good news is that if we can determine cardinatility to be 1, we can also use the currently-unused CodecDataObjectGenerator.Fixed, which offers runtime performance benefits, as noted in .

The ISE is caused by our inability to deal with WildcardType, from whence we should be taking the upper bound – but that will typically not exist, so we'd circle to Object.class and defer to NOOP codec – which is what we have historically done.

While that would happen to work for the concrete case at hand, it is the incorrect thing to do in general.

The List could contain InstanceIdentifier (which needs to be translated to YangInstanceIdentifiers), j.l.Class (which needs to be translated to QNames), or various generated TypeObject subclasses (which need to be decapsulated/translated).

At the end of the day, the current approach to codec lookup is inadequate, as the codec link cannot always be accurately ascertained by pure reflection. This, by the way, also affect leaf nodes, but is hidden by the fact we return an Object and (again) default to NOOP codec.