polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Configuration structure
Date Mon, 05 Jun 2017 09:55:49 GMT
Ok... I'll strip it out.

On Mon, Jun 5, 2017 at 3:41 PM, Paul Merlin <paulmerlin@apache.org> wrote:

> 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.
>>>
>>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message