[CONTROLLER-391] Augmentations are not properly serialized from Java classes into CompositeNode Created: 24/Apr/14  Updated: 25/Jul/23  Resolved: 19/Jun/14

Status: Resolved
Project: controller
Component/s: mdsal
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Alexander Fan Assignee: Amit Mandke
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: Macintosh

External issue ID: 839

 Description   

I've added a new case to the actions in opendaylight-action-types.
augment ".../flow-node:apply-actions/flow-node:action/flow-node:action" {
case color-action-case {
container color-action

{ ... }

}
}

Then, I create a Flow object in Java. I use the respective builders for Instructions, ApplyAction, Action, etc.
Then I insert a ColorAction into this Flow object.

RuntimeGeneratedMappingServiceImpl translates this Java object for Flow into the respective CompositeNode conform.
LazyGeneratedCodecRegistry & TransformerGenerator are used to create a codec for serializing the Flow object.

After serializing, all the namespaces for the nested objects within the Flow object are the SAME.
This is a representation fo the CompositeNode:
/(urn:opendaylight:inventory?revision=2013-08-19)nodes
/(urn:opendaylight:inventory?revision=2013-08-19)node[

{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:-1}

]
/(urn:opendaylight:flow:inventory?revision=2013-08-19)table[

{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=0}

]
/(urn:opendaylight:flow:inventory?revision=2013-08-19)flow[

{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=-123456789}

]
/(urn:opendaylight:flow:inventory?revision=2013-08-19)instructions
/(urn:opendaylight:flow:inventory?revision=2013-08-19)instruction[{}]
/(urn:opendaylight:flow:inventory?revision=2013-08-19)apply-actions
/(urn:opendaylight:flow:inventory?revision=2013-08-19)action[{}]
/(urn:opendaylight:flow:inventory?revision=2013-08-19)color-action

Now, this CompositeNode object is supposed to be inserted into the RESTConf DB.
SchemaAwareDataStoreAdapter fails to properly parse out the color-action CompositeNode because it has the wrong namespace.

 Comments   
Comment by Tony Tkacik [ 24/Apr/14 ]

Moved to YANGTools since this is caused by incorrect translation of Instance Identifier in binding-generator-impl : InstanceIdentifierCodecImpl

Comment by Alexander Fan [ 03/May/14 ]

With the new datastore changes, this same issue arises in a different way.

Explanation of this different way:
Augmentations allow you to append a new case onto an existing choice.
This case node has a DIFFERENT namespace than the existing choice node.

Java object (i.e. Flow) can be successfully converted to CompositeNode, which has all the same namespaces because the serialization passes the Flow's namespace down to all its children.

When converting CompositeNode to NormalizedNode, there are searches for the case node.
In some cases, the case node will have the same namespace as its parent.
In other cases, the case node will have a different namespace than its parent.

====

Added a fix in:
https://git.opendaylight.org/gerrit/#/c/6666/

Comment by Alexander Fan [ 09/May/14 ]

CONTROLLER-391 also has a yangtools component to it.

https://git.opendaylight.org/gerrit/#/c/6822/2

Comment by Tony Tkacik [ 19/May/14 ]

Bit of clarification:
Actual augmentation is addign new cases, which SHOULD have namespace
from declaring YANG module (one that declared augmentation).

It seems that runtime generated codecs for your case did use incorrect namespace.

Comment by Tony Tkacik [ 17/Jun/14 ]

Fixed in https://git.opendaylight.org/gerrit/#/c/8071/2

Generated at Wed Feb 07 19:52:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.