polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <paulmer...@apache.org>
Subject Re: Configuration structure
Date Mon, 05 Jun 2017 07:41:07 GMT
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 <paulmerlin@apache.org> 
> 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.


Mime
View raw message