4:41 a.m.
I am not for or against using properties for config simply because I do not
yet know what the requirements for the configuration will end up being.
On the other hand I feel we should from the start use something that is
capable of handling more structured configuration formats without us needing
to rewrite all the configuration handling code if that need arose (by
abandoning java's Properties and moving to something different).
Hence I propose using Apache Commons Configuration for reading the
configuration files. I think Artificer uses it, too, so Brett et al. can
comment if that would be the right thing to do or not.
Commons configuration supports XPATH for accessing nested data so working with
hierarchical properties should be quite nice with it. The disadvantage is that
it drags several other deps with it -
http://commons.apache.org/proper/commons-configuration/dependencies_1_10.....
Other option could be to commit to a single configuration format and use a
dedicated parser for that with minimal deps. For example if we chose JSON as
the config format we could use JBoss DMR for reading/writing such configs. The
advantage of that approach is that DMR is absolutely tiny with no external
deps. The disadvantage is that JSON cannot have comments (which is easily
amended by a custom reader that would strip the comments before the contents
are passed to DMR for parsing (a recommended approach from the author of JSON
- https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)).
On Thursday, February 05, 2015 11:01:53 Thomas Segismont wrote:
Hi everyone,
Yesterday Lukas asked on IRC if there was a discussion about
configuration. AFAIK, there wasn't, hence I'm sharing how we support
configuration in metrics.
# Metrics REST server
The REST server runs on top of Wildfly.
Configuration is a set of key/value pairs (configuration properties)
defined by the following sources, in order of precedence:
* system properties (-Dkey=value)
* external java.util.Properties file, which path is defined by the
metrics.conf system property; by default, <user.home>/.metrics.conf is
used (if it exists)
* internal java.util.Properties file (META-INF/metrics.conf)
The rationale behind is that the system should be able to:
1. start with reasonable defaults
2. switch to another configuration easily
# pTrans
pTrans is different because it's a standalone application, so it's much
easier to follow the daemon configuration habits.
pTrans takes a path to a properties configuration file as a program
argument. This argument is mandatory.
# Configuration file format.
metrics started with properties file and I think it's fine.
But if we feel the need for a more structured format, we should pick
something which can be easily parsed by a variety of programming
languages, especially languages widely used for administration (Python
and Ruby).
Regards,
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev