8:09 a.m.
I have a few points:
1) pick one way to configure, not N ways. I've since learned that while it is nice
that the agent has so many ways to configure itself (-D cmd line, agent-configuration.xml,
setconfig prompt, -c <file> command line option, config <file> option, etc.)
its a pain to keep track of it all and making sure all of it works and never breaks along
the line.
2) If at all possible, have a single configuration point (a single .xml file for example),
not multiple files and certainly not multiple files in multiple different directories.
3) Why not try to have all our configuration set in standalone.xml? If we are going to be
deployed in Wildfly, it would be nice to have everything (not just our config, but the
config for the wildfly subsystems too) in one place. This also allows us to piggyback on
jboss-cli - we simply use the jboss-cli to have a cmdline interface to our configuration.
4) Keep in mind installation use-cases - don't make configuration so hard that we have
to write a convoluted installer to get things to run.
Note that standalone.xml has a section for just system properties - so if you want to use
system properties as your way of configuration, that can be done in standalone.xml as
well.
Anyway, those are my thoughts. If they can't be done with metrics, or inventory, or
whatever, then so be it. But I take those points above from experience with the RHQ's
configuration.
----- Original Message -----
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
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev