Oh, so the point was than env would be under the portability umbrella versus system properties are not? Kind of makes sense phrased this way for me.
Do we want another thread for that? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-02-16 16:37 GMT+01:00 Kenneth Knowles <k...@google.com>: > > On Thu, Feb 15, 2018, 11:47 PM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >>> >>> 2018-02-15 20:00 GMT+01:00 Kenneth Knowles <k...@google.com>: >>> >>>> On Thu, Feb 15, 2018 at 12:03 AM, Romain Manni-Bucau < >>>> rmannibu...@gmail.com> wrote: >>>>> >>>>> 2. default properties = env + system properties: this is what all >>>>> config libs do (spring config, tamaya, deltaspike, microprofile-config, >>>>> ...) so it is very comfortable and sane for end users. It enables ops >>>>> (env) >>>>> and dev (system properties) to feel comfortable for free with this and >>>>> avoids us to have N entry points which has the nice side effect to >>>>> consolidate the overall consistency of the framework/lib. >>>>> >>>> >>>> Can you link to the docs for these examples? I'm sure we'd like to >>>> learn from them. >>>> >>> >>> I'm not the best to find docs but the relevant bits are: >>> >>> https://github.com/apache/deltaspike/blob/842c84bd1767905a19 >>> e2af01bdfe88d416d1b2da/deltaspike/core/impl/src/main/ >>> java/org/apache/deltaspike/core/impl/config/DefaultConfig >>> SourceProvider.java#L57 >>> https://github.com/apache/geronimo-config/blob/trunk/impl/ >>> src/main/java/org/apache/geronimo/config/DefaultConfigBuilder.java#L182 >>> https://github.com/spring-projects/spring-framework/blob/a0b >>> ce618c2f51d8af1fc00ee2c3868ba2c8e0045/spring-core/src/main/ >>> java/org/springframework/core/env/StandardEnvironment.java#L78 >>> >>> (and there are others a bit less mainstream) >>> >>> The point is just that it is very common to read both and would be weird >>> to not have that feature if we read from system props. >>> >> > I'm convinced that it is common. It isn't clear that it is useful. But > since it has very little impact I'm fine with it. We can take the Java > naming problem to the PR. > > Now the schema for this collection of env vars is a cross-language > question, so we need to make sure Python and Go are on board. > > Kenn >
