.AddConfigServer(environment, ApplicationName, LogFactory), application name not propigated

[stuwilliams-clgx]

When running in PCF using Blue/Green deployment the Blue/Green deployment greeks the application name to include versioning information. The configuration server client code picks up the application name from VCAP_APPLICATION which is a good default behavior, however, in cases where B/G deployment is being used, using the overload .AddConfigServer(environment, *ApplicationName*, LogFactory) allows the ApplicationName to be specified which would allow developers to specify the application name that appears in the Manifest.yml instead. However, this passed value is not respected at run time.

Reproduction Steps:

1. Set up Configuration Server
2. Set up a Git repository
3. Create YML files in the form of {applicationname}-{environment} with the same keys but unique values per environment (aka space)
4. Create a simple app that attempts to get the configuration from the configuration server and then outputs the values to STDOUT so we can see the values in the log
5. Deploy the application to one or more spaces using blue green deployment
6. Verify the app name is the application name in the Manifest.yml file plus the greeked suffix
7. dump the environment vars with cf env ... and the logs with cf logs ... -recent
8. Observe the issue

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161861834

The labels on this github issue will be updated when the story is started.

[dtillman]

@stuwilliams-clgx :

I believe the problem you were having with this was that spring.application.name was always being overridden by the name in the manifest.yml when you pushed the app to PCF. This Steeltoe behavior was not consistent with Java Spring Boot applications.

With Java based apps, if you DID NOT configure spring.application.name, then s.a.n would be set to the application name from manifest.yml. If you DID configure s.a.n, then it would be left alone and remain as configured.

With Steeltoe 2.2, to be released by end of 1st Qtr, we no longer override s.a.n when pushing to PCF (i.e. we follow what Java Spring Boot does).

Also another feature added to Steeltoe 2.2, which will likely will help with B/G, is we added Configuration Placeholder support. This is a new Steeltoe Configuration Provider you can add to your ConfigurationBuilder that enables a Spring like feature called Property Placeholder and placeholder resolution.

This enables you to define configuration keys with values that are placeholders and get resolved at runtime from the other configuration keys/values.

The syntax of a placeholder is of the form: ${some:other:key} or ${some:other:key?default_value_if_not_resolved}.

The some:other:key will be automatically resolved from the apps configuration (likely from some other configuration provider/source (e.g. EnvironmentVariable, CommandLine, etc.). For example, you can use a placeholder for a configuration value that actually gets replaced by a command line parameter or a environment variable setting.

Have a look at the unit tests for examples.

Feel free to reopen another issue if we haven't addressed your needs with the changes in 2.2 of Steeltoe

Dave