[MDSAL-401] Teach AbstractStreamWriterGenerator to keep its mess in its own ClassLoader Created: 19/Nov/18  Updated: 29/Apr/19  Resolved: 29/Apr/19

Status: Resolved
Project: mdsal
Component/s: Binding runtime
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks MDSAL-444 Switch runtime codegen from Javassis... Resolved
is blocked by MDSAL-442 Teach binding-dom-codec to keep its p... Resolved

 Description   

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.

 Comments   
Comment by Robert Varga [ 18/Apr/19 ]

With the infrastructure introduced by MDSAL-442 we do not need to wait for 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.

Generated at Wed Feb 07 20:09:43 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.