native profile includes application.properties/yml and bootstrap.properties.yml

[kennyk65]

When using the native profile, even when you specify the searchLocations, you automatically get application.properties, application.yml, bootstrap.properties, and bootstrap.yml included in your list.

Example: Here is a snippet of my server config (application.yml)

cloud:
  config:
    server:
      native:
        searchLocations: classpath:subfolder/some-local.properties,classpath:subfolder/jubjub.properties

But when my client connects to the server, it sees the following files (log output):

Located property source: CompositePropertySource [name='configService', propertySources=[MapPropertySource [name='applicationConfig: [classpath:subfolder/jubjub.properties]'], MapPropertySource [name='applicationConfig: [classpath:subfolder/some-local.properties]'], MapPropertySource [name='applicationConfig: [classpath:/bootstrap.yml]'], MapPropertySource [name='applicationConfig: [classpath:/application.yml]']]]

The problem here is that my client picks up the port the server is running on, and I get a collision. But there are many reasons why we might not want to expose the server's private configuration.

[dsyer]

There are also many reasons why you wouldn't use the" native" profile - it's only really useful for demos. I don't really think we should change it.

[kennyk65]

Could you describe what some of those reasons are? Having only git-based repository option available isn't very appealing.

[dsyer]

I think the main one is scalability (or availability depending on how you look at it). You need a reliable shared filesystem for the native profile in production - I know that's not impossible, but it isn't very cloudy.

[kennyk65]

For development and other cases this wouldn't be an issue. But if the native should not be used then I'd recommend removing it from the documentation - it threw me off for about an hour.

[dsyer]

I don't want to stop people using it. Feedback is what we need.

[dsyer]

I updated the docs to make it clear that searchLocations should be used and that the filesystem needs to be provided with care in a production system.

[kennyk65]

But the problem is that the server's own application.properties/yml bootstrap.properties/yml will be picked up. If you are doing local development, you'll always need to run more than one app at a time, and if you use native clients will always pick up the port of the server, making this impossible.

[dsyer]

We could change the default search locations I guess. What would be te experience if we did that? Empty properties in all apps. Would that be OK?

[spencergibb]

@dsyer I think the problem comes from here

if (!config.startsWith("application")) {
    config = "application," + config;
}

if spring.application.name=applicationFoo it works. It's the attempt to have application.{yml,properties} be a default. Event if you change the search location, it will pick up config servers application.*.

[kennyk65]

In the end, from a consumers perspective, I'd like to be able to take the same files / structure that I have here: https://github.com/kennyk65/octo-wookie and put them on a local file system (classpath: or file: is fine) and get the same behavior just by specifying the "searchlocation" instead of git repository url. The location of the files should not produce a functional difference. Just my $.02

[dsyer]

Well can't you already do that? (Apart from the inescapable functional difference that got has history and a filesystem does not.)

[kennyk65]

Actually no. When running on Native, the servers own application and bootstrap files are added to what is exposed to the client, so things like the port setting of the server override the port setting on the client. Can't run two apps on the same port on localhost.

[dsyer]

Sorry, I'm a bit slow here, "no" to what?

[kennyk65]

Sorry to be unclear, I was referring to the question "can't you already do that". Answer, no you can't. If I switched from my git repo to local files, I would no longer be able to run both a client and the server on the same machine, as the server would behave differently. It would serve up its internal settings to the client -- including port -- and the client would be unable to start due to the port conflict.