Investigate new manner for deployment and configuration

[mcoffin]

While using typesafe's config library's default mechanism for loading configuration files (via ConfigFactory.load()) works decently for single-application systems, it gets more complex when deploying things as a war like how aion is meant to be deployed.

Consider, for instance, a web application that consists of two wars. One is aion, and another is another application that uses typesafe config. One might have to merge the two configuration files, which would be a pain.

[mcoffin]

The way I see it, there are four ways of going about this.

1. Assert that aion will always be deployed as a single application, like a modern micro-service rather than strictly following the java WAR pattern and being a contained servlet.
2. Use something like OSGi bundle fragments to manage the configuration file, then assert that aion should be deployed in a compatible environment.
3. Move away from typesafe's config library completely.

I'm leaning towards 2 the most right now, as it lets us stay in the java servlets / WAR pattern and lets us stay with the standard typesafe config library. Moving away from typesafe config would require some code changes that wouldn't exactly be fun.

Within option 3, there are a few options.

1. Completely manual management of configuration files in an application-specific manner.
2. Use something like the OSGi configuration admin service to access configuration.

Option 1 would be the least restrictive in terms of how aion is deployed, whereas 2 would definitely be a more standard approach, but would restrict us to OSGi-based deployments (which might not be that big of a deal, so long as we provide an alternative for non-OSGi deployments, which would just be a lot of work).

[mcoffin]

This is blocking #28

[mcoffin]

This is blocking #31

[mcoffin]

Proposed Solution

While all configuration is loaded from a single place (TypeSafe config file) right now. There are really two separate components to configuration.

1. Schema configuration (this includes configuration for any involved SplitStrategy instances.
2. Configuration of individual components, like DataSources

Ideally, DataSource's would be able to choose how they are configured based on how they are discovered (i.e. they could use the OSGi configuration admin service in an OSGi environment, but default back to using TypeSafe config).

In this pluggable way, I think it makes the most sense to start building around loading in an OSGi environment, and using OSGi-style configuration.

• OSGi bundle fragments will be used by a default SchemaProvider instance to load the schema configuration from TypeSafe config files provided by bundle fragments.
• OSGi configuration admin service will be used to configure individual components, like DataSource instantiations (i.e. CassandraDataSource).
• SchemaProvider, DataSource, and SplitStrategy will all be exposed as OSGi services instead of being hard-coded. This implementation will fix #28.