Hi Werner;
and first off, thanks a bunch for your feedback. Even though this
obviously is not a feature packed with tamaya so far, glad to see it at
least has been on the agenda before already... :)
So, to pour in some of our ideas on that... Generally, there are three
different issues we try to solve, configuration-wise:
- "continuous delivery" / deployment to various systems (testbed,
staging, production) without the need to manually change anything in any
of the artifacts deployed, including launcher scripts and all that;
currently our applications (Linux-based) are started using shell
scripts, and this is what made us think about something like the RoR
environments (and possibly an approach to set a system environment
variable which a Java application starter should evaluate), but I am not
sure whether this is the best idea;
- having a sane, clear way of generally managing application
configurations, which becomes painful especially the very moment an
application configuration changes by introducing new keys or options
that are required to be correctly set on all systems; this is where so
far we thought about either deploying all the configuration files in
.properties or .json structures all along with the application (and
having *_production.json, *_testing.json, ... for the different
environments, see above, available on the system), or about having a
central repository (on a file server or in an Apache CouchDB
installation) where each application points to find the configuration to
use on its current host;
- maintaining a structure that includes a notion of "global" and
"application-specific" configurations, knowing that there are things
that are likely to be the same on many or all applications in one
environment (like JDBC URLs for data sources, message bus URLs, REST
endpoints for external systems, SSO integration, ...); so far we had no
real other idea for that but to provide two different sources (files,
documents, ...) for configuration entries - "global" and
"application_XX" ... .
That's, in a nutshell, just a brain dump of our configuration issue so
far. Consequently, we're looking for something that does most of this
and does most of this out of the box. Our current idea, indeed, was to
create something like a local "commons-configuration" implementation
building on top of Apache CouchDB (as a store) and some REST/JSON
library and provide a facade to retrieve global and application specific
configurations for various applications based upon an application name
and an environment descriptor. But then again, I am pretty sure we're
not the only ones dealing with such problems... ;)
All the best,
Kristian
