Bug 2970: Fix GlobalBundleScanningSchemaServiceImpl to get RESOLVED bundles correctly 95/20895/3
authorTom Pantelis <tpanteli@brocade.com>
Sun, 17 May 2015 14:49:00 +0000 (10:49 -0400)
committerGerrit Code Review <gerrit@opendaylight.org>
Thu, 21 May 2015 15:58:04 +0000 (15:58 +0000)
The GlobalBundleScanningSchemaServiceImpl uses a BundleTracker to get
all RESOLVED bundles. When BundleTracker#open() is called
on start(), the BundleTracker will notify addingBundles of all current
bundles that pass the state mask. The OSGi container must resolve all
bundles before activating on startup. So after open() is called we
should have all the current bundles that have yang models and a complete
SchemaContext on startup based on the installed bundles from he last run.
However I was seeing some bundles notified during open() but others notified
later. This why CDS and other components may not see a complete
SchemaContext on startup.

The problem is that GlobalBundleScanningSchemaServiceImpl is passing the
wrong state mask constants. It's referencing constants defined in
BundleEvent but the BundleTracker checks bundle.getState() which
corresponds to constants defined in Bundle. The 2 have slightly
different constants and the values differ. When I change it to use
Bundle constants, it works as expected, ie all current bundles are
notified during open() and we have a complete SchemaContext after start().
I really don't see how this worked before at all using the wrong constants.

I also noticed that start() is being called twice, once in
GlobalBundleScanningSchemaServiceImpl#createInstance and then also in
the Activator after it calls createInstance. So 2 instances of
BundleTracker were being created resulting in double the notifications.
I removed the call to start() in the Activator.

Change-Id: I8c8330f75dd1a779af186688aae4cfaee89bd43b
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>

No differences found