Remove CSS code JIRA: TSC-111 Change-Id: Ib74c1d3dfc029c2472b8834ae55ce05c8231d225 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Remove yang-test This needs to be removed before the rest of CSS as it uses yang-test-plugin which is hard-coded in auto-realease. So need to remove yang-test first from controller then remove yang-test-plugin from auto-realease. Change-Id: I399de2684e93b267ec5fcdd5365b31384e5dded0 Signed-off-by: Tom Pantelis <tompantelis@gmail.com>
Fix checkstyle reported by odlparent-3.0.0 Change-Id: I08c548fbbbef8527ad7b037b0def33d3c1c09bf6 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Fix checkstyle issues to enforce it Fix checkstyle issues to enforce it. Change-Id: I306255919cdfe43208d7c254f2f6455f4126b92f Signed-off-by: David Suarez <david.suarez.fuentes@gmail.com>
StringBuffer cleanup This patch cleans up StringBuffer use, mostly replacing StringBuffer with StringBuilder or plain String concatenation for short sequences (or constants). * HexEncode: additionally, avoid using a separate return variable, drop the useless ":" handling in bytesToHexString(), and add the test class from l2switch. * HardcodedModuleFactoriesResolver: rework the conflicting module handling. Change-Id: Id76e91bba9ce40bd8ed5947c2d40e3a7baf0a949 Signed-off-by: Stephen Kitt <skitt@redhat.com>
config-manager: final parameters This automatically-generated patch flags all appropriate parameters as final (including caught exceptions). Change-Id: I78de8a8a8f9766a654432e8ba5a0497f06c4438a Signed-off-by: Stephen Kitt <skitt@redhat.com>
Fix Eclipse warnings in config-manager Change-Id: I0ed9bc52d4cf4e5ee7a4da8bd53355191326cba6 Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Bug 6859 - Binding generator v1 refactoring Based on transfer of Binding generator v1 from Yangtools project to MDSAL in past, we need to finalize this process by refactoring package naming: org.opendaylight.yangtools -> org.mdsal.binding org.opendaylight.yangtools.sal -> org.mdsal.binding Refactoring changes in MDSAL, see: https://git.opendaylight.org/gerrit/#/c/52107 By using of Binding generator v1, this change needs to be addressed in Controller project. - refactoring itself - add META-INF to gitignore Change-Id: Ib7ec1b39466c0c814459bcbc2adce437b2a0ca64 Signed-off-by: Jakub Toth <jatoth@cisco.com> Signed-off-by: Robert Varga <rovarga@cisco.com>
Fixed few sonar warnings. Removed static imports. Change-Id: Ife05c6c4fc288c70624880eefbe9c5be8b47b974 Signed-off-by: Dana Kutenicsova <dana.kutenics@gmail.com>
Mechanical code cleanup (config) * Remove unnecessary type specifiers (use Java 7 <>) * Remove unnecessary "extends Object" declarations * Remove unnecessary semi-colons * Merge identical catch blocks * Remove redundant modifiers: - enum constructors are private by default - interface properties are public static final by default - interface methods are public abstract by default - interfaces are abstract by default - inner interfaces are static by default - inner classes in interfaces are public static by default Change-Id: Iefd8363a5eb120fdd43a4632b9e3db0e7e347dba Signed-off-by: Stephen Kitt <skitt@redhat.com>
Improve config system shutdown On shutdown, the ModuleFactoryBundleTracker is invoked for every removed bundle which executes the "blank" transaction which in turn calls ConfigRegistryImpl#beginConfig. This method is synchronized and may block if a config commit is in progress (which might be waiting on capabilities or a ModuleFactory). The ModuleFactoryBundleTracker is invoked synchronously so this can block karaf shut down. It can affect single feature tests in particular which start and stop karaf quickly. I'm not exactly sure what the blank tx is for - I think its purpose is to indirectly cause the deactivated bundle's module(s) to be destroyed. On shutdown, the ConfigManagerActivator stop method calls ConfigRegistryImpl#close which destroys all the modules so we really don't need the blank tx to run on every bundle on shutdown. On shutdown, karaf first sends a STOPPING event for the system bundle (id 0). So I added the ConfigManagerActivator as a bundle listener and when the system bundle 0 transitions to STOPPING, it calls ConfigRegistryImpl#close. I also added a closed flag in ConfigRegistryImpl which is checked by beginConfig and commitConfig. In order to make this work right, I had to change the synchronization in ConfigRegistryImpl, which really was over-synchronized on "this". I removed synchronized from the beginConfig and close methods to break the locking between the two and I made ConfigHolder and TransactionsHolder classes thread-safe by using ConcurrentHashMap which allows close to access them safely w/o synchronization. If the closed flag is set, beginConfig returns a no-op ObjectName, otherwise it calls the synchronized beginConfigSafe method. In commitConfig, if closed is set or the ON is the no-op ObjectName, it returns an an empty CommitStatus. I also changed from synchronizing "this" to using a Lock to take advantage of the tryLock functionality. As an added measure of safety against prolonged blocking, if beginConfig is called with the blank tx flag set, it tries to acquire the lock for 5 sec. If it fails it returns the no-op ObjectName. After the modules are destroyed by ConfigRegistryImpl#close. the container will proceed to stop the rest of the bundles and the ModuleFactoryBundleTracker will initiate blank transactions but they'll be no-ops and won't block. The ModuleFactoryBundleTracker was also changed to only initiate a blank transaction for bundles that contain a ModuleFactory (via Boolean state stored with the BundleTracker). With these changes, karaf shuts down noticeably faster. The BlankTransactionServiceTracker also initiates a blank transaction when services are added and removed. Since these are synchronous calls we really shouldn't block the OSGi container. So I added a single-threaded executor to process the blank transactions for the service changes. The blank transaction on bundle removed has to be done synchronously as it may still need access to the BundleContext which becomes invalid after the bundle removed event. Change-Id: I5482caa4182dcc64df9b6bafefac9b8f2d505d3e Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
BUG-4514: clean children in InternalJMXRegistrator Retaining children once they have been closed can lead to a leak, make sure we call back to parent to remove ourselves from its list. This includes a refactor to hide InternalJMXRegistrator, which becomes abstract and has two subclasses: Root and Nested. This allows us to use proper synchronization between closing of the child and parent registrators. Also saves a bit of memory. Also clean up {Module,Transaction}JMXRegistrator constructors to not do a createChild(), as that fails to cleanup immediate children of the Root, leading to empty InternalJMXRegistrators being collected in Root's child list. Change-Id: I9a4708b67777ca6033e5a83c586b3f78692dff2a Signed-off-by: Robert Varga <rovarga@cisco.com>
Modify ModuleInfoBundleTracker to track RESOLVED bundles (round 2) My first patch https://git.opendaylight.org/gerrit/#/c/27138/ didn't do well with the feature tests due the BundleContext bust wait so it was reverted. I went back to my original solution to confgure the ModuleInfoBundleTracker to track RESOLVED and ModuleFactoryBundleTracker to track ACTIVE. Originally when I tried that I had some failure due to the ModuleFactory not loaded yet but I don't remember exactly what. This patch seems to work fine - I've restarted karaf several times and also ran the tsdr features tests several times successfully. Originally I did the first patch in stable/lithium so maybe something else has changed in master or the way I did it wasn't right. Since the initial yang module info's are now processed synchronously when the BundleTracker is opened, I modified the ModuleInfoBundleTracker to ensure it doesn't propagate runtime ex's. This would disrupt the BundleTracker and the ConfigManagerActivator - if one module had an issue the config manager wouldn't start. For every YangModuleInfo scraped, it registers it with the ModuleInfoRegistry. The backing impl is RefreshingSCPModuleInfoRegistry which causes a new SchemaContext to be created from the current yang models (via updateService). This isn't efficient - on startup, we'll get all YangModuleInfo's in quick succession so, optimially, it should build the SchemaContext once after open is complete. This is what the GlobalBundleScanningSchemaServiceImpl does. To accomplish this, I removed the call to updateService from RefreshingSCPModuleInfoRegistry#registerModuleInfo - it is now specifically called by ModuleInfoBundleTracker. This means the ModuleInfoBundleTracker now references RefreshingSCPModuleInfoRegistry instead of the ModuleInfoRegistry interface which makes it less clean. Any other way would require changes to the ModuleInfoRegistry interface, which I didn't want to do, or extending the interface which I didn't think that was worth the effort. The RefreshingSCPModuleInfoRegistry is only used by ModuleInfoBundleTracker. Change-Id: I20213ce8bd1dfc5109f3ef223cec8048bec92e12 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
BUG-4367: Use SchemaSourceProvider to retrieve sources for yang - Not using schema context to provide the sources anymore. - Transform the modules into capabilities in YangStoreService instead of requiring the listeners to do so Change-Id: I39a144c7472f7944cca01eeff273058aa2fe7d7a Signed-off-by: Maros Marsalek <mmarsale@cisco.com>
Revert ModuleInfoBundleTracker patches Reverted patch https://git.opendaylight.org/gerrit/#/c/27138/ as it causes some feature tests to take a long time due to the busy wait. Also it appears the ModuleFactory OSGi services are needed as the BlankTransactionServiceTracker listens for them (I'm not clear what this does). I'll try to figure out another way to accomplish the intent of the reverted patch. Change-Id: Ifc91dada86ac7feee1a0a9390a55e68d7f113153 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Fix ModuleFactoryBundleTracker shutdown hang If karaf is shutdown quickly after starting, the ModuleFactoryBundleTracker#getModuleFactoryEntries method may hang for a while trying to obtain BundleContexts. This has been seen on jenkins with some feature tests. The ModuleFactoryBundleTracker does a 1 min busy wait trying to obtain the BundleContext. This was done b/c the tracker listens for RESOLVED bundles and the BundleContext isn't available until after the bundle is started. So the busy wait was intended for startup when bundles transition from RESOLVED -> STARTING. Once obtained, the BundleContext is cached. This works fine normally when all bundles start up. However, if stopped quickly, some bundles may not have started, ie they remain in the RESOLVED state with null BundleContext, so on shutdown when someone calls getModuleFactoryEntries, it will busy wait and eventually timeout which can take minutes. What we need to do is remove the ModuleFactory entries when bundles are stopped. The ModuleFactoryBundleTracker#removedBundle method does this but it wasn't called on shutdown b/c it tracks RESOLVED, STARTING, ACTIVE and STOPPING states. The solution is to remove STOPPING from the tracked states so removedBundle will get called on transition ACTIVE -> STOPPING. However, when transition STOPPING -> RESOLVED occurs the bundle will get added back to the tracker and we don't want to re-add the ModuleFactory entries. To prevent this it checks for BundleEvent type STOPPED. Change-Id: I82889a682809d4217dc4253eb60c922209ad7242 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
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>
Decouple config and netconf subsystems. Extract a common mapping for config pusher and config subsystem netconf Add a ConfigPersisterFacade for XML that allows reads/writes from/to config subsystem using XML format Push notifications from YangStoreService to NetconfNotificationManager instead of using custom listeners Migrate netconf features from controller features, untangle features Change-Id: I71e4ca6e0258e0b1f0d6c19119f93eb9d68b7bca Signed-off-by: Tomas Cere <tcere@cisco.com> Signed-off-by: Maros Marsalek <mmarsale@cisco.com> Signed-off-by: Ed Warnicke <hagbard@gmail.com>
Fix license header violations in config-manager Change-Id: I8144512cd8093fbcc0851de66490f866ec8bb7c4 Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>
BUG 2839: Config: remove dependencies on commons-io Migrated commons-io users to guava and custom solutions when there were no alternatives in guava. Change-Id: I399030df1fbd7ea6e40b2591346802068e32f681 Signed-off-by: Tomas Cere <tcere@cisco.com>