https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-401 mdsal <p>Once we implement <a href="https://jira.opendaylight.org/browse/MDSAL-392" title="Clean up BindingRuntimeContext instantiation" class="issue-link" data-issue-key="MDSAL-392"><del>MDSAL-392</del></a>, we'll get a static map of ClassLoaders which participate on a particular BindingRuntimeContext, without any guesswork whatsover and we get this update atomically.</p> <p>This is a boon, as we can properly construct our ClassPool, eliminating the need to use JavassistUtils.appendClassLoaderIfMissing(), as we can always find binding classes for a BindingRuntimeContext.</p> <p>The direct implication is that for a particular BindingRuntimeContext generation we can generate codecs into a properly-controller ClassLoader so they do end up being thrown with interface classes.</p> <p>This has the upshot that we do not leave crud if ever mdsal-binding-dom-adapter/codec are reloaded, hopefully fixing frozenClass exceptions once and for all.</p> <p>Furthermore we can make sure AbstractStreamWriterGenerator.generateEmitter0() runs with the codec class loader visible, meaning we can properly initialize the prototypes without having to play tricks with reflection and late value injection.</p> MDSAL-401

Teach AbstractStreamWriterGenerator to keep its mess in its own ClassLoader

Improvement Medium Resolved Done Robert Varga Robert Varga Mon, 19 Nov 2018 17:39:33 +0000 Mon, 29 Apr 2019 14:51:16 +0000 Mon, 29 Apr 2019 14:51:16 +0000 4.0.1 Binding runtime 0 1 <p>With the infrastructure introduced by <a href="https://jira.opendaylight.org/browse/MDSAL-442" title="Teach binding-dom-codec to keep its proxies in a separate ClassLoader" class="issue-link" data-issue-key="MDSAL-442"><del>MDSAL-442</del></a> we do not need to wait for <a href="https://jira.opendaylight.org/browse/MDSAL-392" title="Clean up BindingRuntimeContext instantiation" class="issue-link" data-issue-key="MDSAL-392"><del>MDSAL-392</del></a>, as we have a clean multi-classloader support in place. As it turns out the entire StreamWriter machinery is needlessly complicated, as it used to support Config Subsystem and also it relies on yang-binding interfaces.</p> <p>Due to API stability, we cannot just ditch the mechanics and refactor the generator to be properly implemented, hence the patch to resolve this should provide a forked implementation, integrated into BindingCodecContext, which does not live in gen.impl, but rather directly in the binding-dom-codec proper, being an implementation detail.</p> <p>Generated stream writers should also not be based on yang-binding concepts, but rather on interfaces/classes private to binding-dom-codec, so they are not leaked to the Binding Specification and be properly co-evolved with the codec.</p> <p>Once such an implementation is present, all interfaces and classes supporting the legacy writers and not used by the new ones should be deprecated and then removed in 5.0.0 timeframe.</p> Blocks MDSAL-444 MDSAL-442 Development Rank 0|i03ku7: