Details
-
Epic
-
Status: Resolved
-
Medium
-
Resolution: Done
-
None
-
None
Description
DOM OSGi SchemaContext services and the interaction between binding codec, adapter are quite a bit perplexing. The wiring should really be simplified, so that we can arrive at a place where the codec tree is completely predictable and does not rely on TCCL.
One key ingredient we seem to be missing is that the set of ClassLoaders from which a particular SchemaContext should be carried with it.
Attachments
Issue Links
- blocks
-
CONTROLLER-1882 Inject DataBroker only when all shards have leaders
-
- Resolved
-
-
MDSAL-525 Eliminate blueprint from mdsal-binding-dom-adapter
-
- Resolved
-
- is duplicated by
-
MDSAL-250 Eliminate duplicate YangTextSchemaContextResolvers
- Resolved