Startup Sequence / Dependency Management
Since in OSGi, startup is asynchronous, it is hard to tell when the server is initialized, especially when you have to deal with dynamic bundle installing. With OSGI’s dependency management, it is difficult to figure out when a dependency has fully loaded and non-deterministic load orders can create heisenbugs. Whereas the config subsystem provides a relatively simple way to express such dependencies and have the implementation made available to them locally.
Config subsystem looks at bundles as they arrive, parses their yang files and announces them in hello message.
Required-capabilities in the configuration xml file specifies which applications must be loaded before the xml file is pushed. So the component that pushes the xmls to netconf server does a lot of speculative connects, waits until all bundles required for given xml are present and only then issues edit-config.
New configurations can be provided, either in total or just changing some parts, by using NETCONF to update the configuration. Applications are notified of the change and can either process the change appropriately or reject it.
The OSGi framework provides configuration service and allows runtime module configuration. However, it still lacks a validation process: a new module configuration can negatively affect other modules. It also does not solve problems relating to the atomicity of the change.
To secure the consistency and safety of a new configuration, and to avoid conflicts, the configuration validation process is necessary. Usually, validation checks the input parameters of a new configuration and mostly verifies module-specific relationships. The validation procedure results in a decision indicating whether the proposed configuration is healthy.