Modify ModuleInfoBundleTracker to track RESOLVED bundles 38/27138/5
authorTom Pantelis <tpanteli@brocade.com>
Sun, 13 Sep 2015 03:55:29 +0000 (23:55 -0400)
committerGerrit Code Review <gerrit@opendaylight.org>
Tue, 29 Sep 2015 13:43:20 +0000 (13:43 +0000)
commit493c4f70a0a315d77927e4c0d90a90acbbcb2897
treeee00688c3a762fec947843908637b3caa1884aa6
parent7873bfcd1735ce86a58c015b2865c7f3627fb121
Modify ModuleInfoBundleTracker to track RESOLVED bundles

I've seen issues where a yang-generated class that exists in another
bundle isn't found on startup when a module config is pushed.
Specifically I've seen it when registering RPC implementations. The
BindingDOMRpcProviderServiceAdapter uses the
BindingToNormalizedNodeCodec get the RPC schema and it can fail to
get the RPC input class.

The BindingToNormalizedNodeCodec calls the BindingRuntimeContext to
obtain schema classes which in turn uses the ClassLoadingStrategy OSGi
service to load classes. The backing implementation of
ClassLoadingStrategy is the ModuleInfoBackedContext supplied by the
config manager bundle. This is backed by the ModuleInfoBundleTracker
which scrapes yang files from bundles. However it listens for ACTIVE
bundles. A while ago the GlobalBundleScanningSchemaServiceImpl was
(correctly) changed to listen for RESOLVED bundles which fixed startup
timing issues. It makes sense to also change the
ModuleInfoBundleTracker to listen for RESOLVED bundles so all existing
yang models are loaded on startup prior to use.

The ModuleFactoryBundleTracker piggy-backs the ModuleInfoBundleTracker
to load ModuleFactory instances needed by the config system. It
registers ModuleFactory instances as OSGi services, which are consumed by the
BundleContextBackedModuleFactoriesResolver, however this fails for a
RESOLVED bundle b/c it doesn't have a BundleContext yet (apparently this
is set when the bundle is started/activated). To fix this, I refactored
BundleContextBackedModuleFactoriesResolver and
ModuleFactoryBundleTracker a bit. The ModuleFactoryBundleTracker no
longer registers ModuleFactory instances as OSGi services. Instead it
maintains a list of ModuleFactory/Bundle entries which the
BundleContextBackedModuleFactoriesResolver directly uses to build the
resulting factories map for the ConfigRegistry. A bundle may still not
have a BundleContext at that point so, to safe guard against that, I
added a busy wait for BundleContext.

Change-Id: Ia7bd39f635e3473e6e84011163a0768865c9a931
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
opendaylight/config/config-manager/src/main/java/org/opendaylight/controller/config/manager/impl/osgi/BundleContextBackedModuleFactoriesResolver.java
opendaylight/config/config-manager/src/main/java/org/opendaylight/controller/config/manager/impl/osgi/ConfigManagerActivator.java
opendaylight/config/config-manager/src/main/java/org/opendaylight/controller/config/manager/impl/osgi/ExtensibleBundleTracker.java
opendaylight/config/config-manager/src/main/java/org/opendaylight/controller/config/manager/impl/osgi/ModuleFactoryBundleTracker.java
opendaylight/config/config-manager/src/test/java/org/opendaylight/controller/config/manager/impl/osgi/BundleContextBackedModuleFactoriesResolverTest.java
opendaylight/config/config-manager/src/test/java/org/opendaylight/controller/config/manager/impl/osgi/ModuleFactoryBundleTrackerTest.java