[MDSAL-600] RuntimeTypeGenerator does not handle TypeDefinition equality contract Created: 18/Oct/20 Updated: 19/Oct/20 Resolved: 19/Oct/20 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding runtime |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.1 |
| Type: | Bug | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | regression | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Doing something (weird) like this: container foo {
leaf bar {
type enumeration {
enum foo {
value 0;
description "does not even matter";
}
enum bar {
value 1;
}
}
}
leaf baz {
type enumeration {
enum foo {
value 0;
}
enum bar {
value 1;
reference "is useless as well";
}
}
}
}
wrecks the runtime rather completely with: com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalArgumentException: value already present: BaseEnumerationType{name=(urn:xxx)enumeration, status=CURRENT, values=[EnumPairImpl{name=foo, value=0}, EnumPairImpl{name=bar, value=1}]}
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2051)
at com.google.common.cache.LocalCache.get(LocalCache.java:3951)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4958)
at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4964)
at org.opendaylight.mdsal.binding.dom.adapter.test.AbstractSchemaAwareTest.getRuntimeContext(AbstractSchemaAwareTest.java:41)
at org.opendaylight.mdsal.binding.dom.adapter.test.AbstractSchemaAwareTest.setup(AbstractSchemaAwareTest.java:33)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:542)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:770)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:464)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
Caused by: java.lang.IllegalArgumentException: value already present: BaseEnumerationType{name=(urn:xxx)enumeration, status=CURRENT, values=[EnumPairImpl{name=foo, value=0}, EnumPairImpl{name=bar, value=1}]}
at com.google.common.collect.HashBiMap.put(HashBiMap.java:289)
at com.google.common.collect.HashBiMap.put(HashBiMap.java:270)
at org.opendaylight.mdsal.binding.generator.impl.RuntimeTypeGenerator.toTypeMapping(RuntimeTypeGenerator.java:58)
at org.opendaylight.mdsal.binding.generator.impl.DefaultBindingRuntimeGenerator.generateTypeMapping(DefaultBindingRuntimeGenerator.java:43)
at org.opendaylight.mdsal.binding.runtime.spi.BindingRuntimeHelpers.createRuntimeContext(BindingRuntimeHelpers.java:89)
at org.opendaylight.mdsal.binding.dom.adapter.test.AbstractSchemaAwareTest$1.load(AbstractSchemaAwareTest.java:27)
at org.opendaylight.mdsal.binding.dom.adapter.test.AbstractSchemaAwareTest$1.load(AbstractSchemaAwareTest.java:1)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045)
... 33 more
The problem is that the equality contract for TypeDefinition has changed such that it follows semantics. Previously we were guarded by SchemaPath being part of equals() but now it's just the QName (as of YT-6) Hence unrelated type definitions which are semantically equivalent end up throwing off the BiMap contract. Long-term we want to ditch equality completely, opting for identity, but we are at half way and need to handle this. The primary problem is assumptions in BiMap, which used to be fair, and will be fair again (at which point WithStatus/SchemaNode will be going away), so we need a story right now.
|
| Comments |
| Comment by Emmanuelle Delfour [ 19/Oct/20 ] |
|
Hello, |