Added filters while listing scoped configuration parameters.
Fixed: Some parameters are missing from UI settings tab because of missing scope entry in configuration table.
Signed-off-by: Koushik Das <koushik@apache.org>
Removing resource leaks from UsageSanityChecker and
refactoring it (encapsulation, removal of copy and paste, constants...)
Modularize static method for closing Statments in TransactionLegacy
and reusing this new method from other classes (Upgrade2214to30)
Create Unit and Integration Tests for UsageSanityChecker
Add DBUnit cases and integration profile for nitegration tests as
a base for future DB tests
Discovery of modules is based on classpath scanning. In some situations it
may not be possible or desirable to change the classpath. To force a
module to not load you can create a file called modules.properties on the
classpath that can exclude specific modules from loading. Additionally
this same file can be used to exclude a specific extension. Extension
loading is typically done through global configuration. If you want to set
up an environment and you don't even want the extension/module loaded on
the first start, then using the config file is appropriate.
Example: modules.properties
modules.exclude=storage-image-s3,storage-volume-solidfire
extensions.exclude=ClusterScopeStoragePoolAllocator,ZoneWideStoragePoolAllocator
Typically you would want to place this file in /etc/cloudstack/management
xs 6.1/6.2 introduce the new virtual platform, so there are two virtual platforms, windows PV driver version must match virtual platforms,
this patch tracks PV driver versions in vm details and template details.
Anthony
Introduction of a new Transaction API that is more consistent with the style
of Spring's transaction managment. The existing Transaction class was renamed
to TransactionLegacy. All of the non-DAO code in the management server has been
updated to use the new Transaction API.
Previously ConfigurationDao and ConfigDepot was in the bootstrap context
which was not needed. Moving down to system to be more consistent with
the database upgrade checks.
ACS is now comprised of a hierarchy of spring application contexts.
Each plugin can contribute configuration files to add to an existing
module or create it's own module.
Additionally, for the mgmt server, ACS custom AOP is no longer used
and instead we use Spring AOP to manage interceptors.
The managed context framework provides a simple way to add logic
to ACS at the various entry points of the system. As threads are
launched and ran listeners can be registered for onEntry or onLeave
of the managed context. This framework will be used specifically
to handle DB transaction checking and setting up the CallContext.
This framework is need to transition away from ACS custom AOP to
Spring AOP.
