while working on CONTROLLER-1831 and reviewing blueprint wiring XML in controller, I realized that controller/opendaylight/md-sal/mdsal-trace/binding-impl/src/main/resources/org/opendaylight/blueprint/impl-blueprint.xml creates a 2nd BindingToNormalizedNodeCodec, in parallel to the original supposedly singleton one (from opendaylight/md-sal/sal-binding-broker/src/main/resources/org/opendaylight/blueprint/binding-broker.xml), via the BindingToNormalizedNodeCodecFactory, which tpantelis and I yesterday discussed we'll remove as part of CONTROLLER-1831.

Having x2 separate BindingToNormalizedNodeCodec, with separate classloading, when the Transaction Trace tool is installed (only), smells like asking for trouble... in fact, I'm wondering if perhaps this could be causing MDSAL-213 !?

I'll raise a Gerrit with a propose change to do this differently ASAP.