Teach AbstractStreamWriterGenerator to keep its mess in its own ClassLoader
Description
blocks
is blocked by
Activity
Robert Varga April 18, 2019 at 3:29 PM
With the infrastructure introduced by https://lf-opendaylight.atlassian.net/browse/MDSAL-442#icft=MDSAL-442 we do not need to wait for https://lf-opendaylight.atlassian.net/browse/MDSAL-392#icft=MDSAL-392, 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.
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.
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.
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.
Details
Assignee
Robert VargaRobert VargaReporter
Robert VargaRobert VargaComponents
Fix versions
Priority
Medium
Details
Details
Assignee
Robert VargaReporter
Robert VargaComponents
Fix versions
Priority
Medium
Once we implement MDSAL-392, we'll get a static map of ClassLoaders which participate on a particular BindingRuntimeContext, without any guesswork whatsover and we get this update atomically.
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.
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.
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.
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.