Le 2017-06-04 16:09, Niclas Hedhman a écrit :
By that rationale, we should remove properties/xml/json/yaml files as
well,
right?
:)
Yeah, maybe, maybe not.
What I dislike in the added logic is that it exposes the application to
the environment through a naming convention that does not involve
structure nor service identity. Properties/xml/json/yaml at least need
to be named according to the configured service identity. And I see them
as almost immutable (classpath assembled at build time). For editable
configuration defaults I rely on ad-hoc application configuration files
applied at assembly time.
I better see a SPI for configuration defaults. Extensions for this SPI
could then use the environment, system properties, or anything else
really. They could apply any named convention, or just pick some things
from the environment.
I then picture an implementation backed by e.g. Typesafe Config for nice
configuration files.
It supports using environment variables and system properties, but
explicitly.
One could then have a single `application.conf` file, here's a quick
example:
some_service_identity:
aStringProperty = with some text
anEnvironmentVariable = ${MY_ENV_VAR}
another_service:
somethingElse = 42
Setting the `some_service_identity.aStringProperty` system property then
override its value.
See https://github.com/typesafehub/config
Other implementations backed by etcd, zookeeper, consul etc.. could be
provided for advanced deployments.
All in all I'd be in favor of not adding any magic to 3.0 and think
about a more holistic solution for 3.1.
WDYT?
Cheers
/Paul
On Sun, Jun 4, 2017 at 8:37 PM, Paul Merlin <[email protected]>
wrote:
Le 2017-06-04 13:23, Niclas Hedhman a écrit :
initialValueProvider should be marked "incomplete" or something.
I'd rather simply remove it from the api for now.
I'll do that if no one yell :)
For the rest, not so sure I like it. I think I would prefer something
more
composite-like, but not sure yet.
One thing that is already possible is to declare defaults at assembly,
getting system properties/env at that time. That's how I do for my
apps and
I like the explicitness.
module.forMixins( MyConfig.class )
.declareDefaults()
.myProperty().set( System.getenv( "SOME_THING_WHATEVER_THE_NAME"
) );
Just to say, I'm not sure I like the extra magic.
I'd favor it to be opt-in. But I'd be happy with a way to opt-out too.
