Generate environment variables with default values for configuration values

[ddobrin]

Codegen generates a number of configuration files, with their associated default values.

For example: server.yml
...
httpsPort: 8443
enableHttps: true
...

Some of these values must change between the different test phases, all the way to production.
to this end, the Config module has been changed recently to support variables, which can be changed between environments.

This issue wishes to assist developers by generating the variables for each of these elements, together with the associated default values.
Teams can decide whether they wish to use these variables and change the defaults or not.

The newly generated files will look similar to:
...
httpsPort: ${server.httpsPort:8443}
enableHttps: ${server.enableHttps:true}
...
and use a clear and unique naming convention, based on .

The change is backwards compatible 100%

The need arises from the discussions associated with the following PR as well as the desire from large consumers to set specific values per environment:
networknt/light-rfcs#7

[DSchrupert]

I don't agree with this change at all.

By default we're now generating config that is injectable with environment variables?

1. If ops forgets to assign one of the environment variables, we're now going to fall back to a dev value.. that's going to make debugging much more difficult and prone to unexpected behaviour.
2. For developers to now have to deal with their config value looking like this vs before.. it's a lot more difficult to read and find what you're looking for. Literally the opposite outcome of where this whole issue started.
3. 100% backwards compatable? ... as long as no one was using these environment variables already for other purposes.
4. And why is this just on server.yml? I would expect if someone was willing to use this they would prefer to have it applied everywhere..

[ddobrin]

That file was committed with another change too early.
All other files in templates and templates.rest have been updated at this time.

[ddobrin]

1. If somebody is not setting the value in ops, they are getting the same default value today
2. Developers can use the values.yml to set anything they wish to change past default, which they do today if they choose to do so
3. the change is backwards compatible, as the generated code has the exact same behaviour as in the past
4. Please see the previous comment

[stevehu]

@NicholasAzar I have the same concerns after reading your comments as backward compatibility is crucial for us now. I did a test with openapi petstore and the result is promising. The project was generated and started without any issue with the old config.json file. I found one issue with the generated petstore project that the Pet and Error POJOs are missing. I am wondering if this is a bug newly introduced. The petstore is still working as it is not using these POJOs.

[ddobrin]

I ran the generator at my client across multiple APIs and I found some gaps, addressed in issues in light-codegen, light-rest-4j and a new issue in light-4j.

I'll share it offline with you

[ddobrin]

Issue #214 addresses the POJOs which were not generated when allOf is used.

The issue was introduced by a recent change in the codegen on an unrelated issue, affecting the generation.

All OpenAPI specs are working fine at my client

[DSchrupert]

• If somebody is not setting the value in ops, they are getting the same default value today
• Developers can use the values.yml to set anything they wish to change past default, which they do today if they choose to do so
• the change is backwards compatible, as the generated code has the exact same behaviour as in the past
• Please see the previous comment

1. I don't think so.. defaulting is on the file level. If the config modules finds a file exists higher in the hierarchy it will never go back to default values. If we start standardizing on environment substitution everywhere (which again, I think is a bad idea), then a particular unset field in the environment will use a dev value when it wouldn't have before.
2. You didn't address my point at all.
3. As I said, it's expected to be backwards compatible with the caveat that any environments where these will be running don't already use these environment variables for other purposes.

[ddobrin]

I think that you need to look at the Config module then. If a developer sets a variable in his/her api, and it has defaults, then builds the jar and makes it available to an ops guy, the expectation is that: -ops guy sets the value In values.yml or commas line. Today the ops guys provide a new file with overridden values. -if the ops guy doesn’t set the value, then the default takes hold. It is the same like today. Ex: if you disable http2 and build the jar and the ops guys doesn’t override server.yml, it will be used with http2 disabled. If the config module doesn’t respect fhis, then we should rethink all of this.

On Wed, Jan 30, 2019 at 10:12 AM Nicholas Azar ***@***.***> wrote: - If somebody is not setting the value in ops, they are getting the same default value today - Developers can use the values.yml to set anything they wish to change past default, which they do today if they choose to do so - the change is backwards compatible, as the generated code has the exact same behaviour as in the past - Please see the previous comment 1. I don't think so.. defaulting is on the file level. If the config modules finds a file exists higher in the hierarchy it will never go back to default values. If we start standardizing on environment substitution everywhere (which again, I think is a bad idea), then a particular unset field in the environment will use a dev value when it wouldn't have before. 2. You didn't address my point at all. 3. As I said, it's expected to be backwards compatible with the caveat that any environments where these will be running don't already use these environment variables for other purposes. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATRXEW0zRt6kotGuat2iNklOjcZkgDo2ks5vIbZbgaJpZM4aTfQB> .

-- Dan C. Dobrin Software Architect & Ultrarunner ---------------------------------------------------------- Sun Certified Enterprise Architect for Java Platform Email: dan.dobrin@gmail.com