title: Issue overriding application properties in Spring-boot (profile-specific) application launched with PropertiesLauncher
body: <p>I'm having difficulty trying to override a property declared in a profile-specific application properties file on the classpath with another value declared in an overrides file on the file system.</p>
  
  <p>I have an auto-configured Spring-boot application (that is, using <code>@EnableAutoconfiguration</code>) that has multiple profiles, which I launch using <code>PropertiesLauncher</code> rather than <code>JarLauncher</code> (the reason having to do with deployment constraints - I need to deploy an exploded directory rather than an archive into a <strong>read-only</strong> filesystem.)</p>
  
  <p>Within the root of my application, I have some profile-specific application properties, for example:</p>
  
  <pre><code>application-dev.properties
  application-qa.properties
  application-prd.properties
  </code></pre>
  
  <p>And let's say, for the sake of argument that <code>application-dev.properties</code> contains:</p>
  
  <pre><code>foo.bar=baz
  foo.baz=other
  </code></pre>
  
  <p>For any environment, it may be necessary to override an <em>existing</em> property, as well as supply an <em>absent</em> one (like a production password, for example), and the issue I'm seeing is with overriding properties already declared in an <code>application-${profile}.properties</code> file on the classpath. (Supplying properties not present in the classpath file works fine, this is <strong>not</strong> the issue.)</p>
  
  <p>Say I have an overrides properties file in a file system location such as:</p>
  
  <pre><code>/local/appname/dev/overrides/application.properties
  </code></pre>
  
  <p>and I want to override the property, <code>foo.bar</code>, as well as declare a new property, <code>foo.password</code>.</p>
  
  <p>Therefore the contents of the overrides file are:</p>
  
  <pre><code>foo.bar=overridden-value
  foo.password=something
  </code></pre>
  
  <p>When I launch the application, I use a command line something like this:</p>
  
  <pre><code>java -Dspring.config.location=file:/local/appname/dev/overrides/ 
       -Dspring.profiles.active=dev 
       org.springframework.boot.loader.PropertiesLauncher 
       --debug &amp;
  </code></pre>
  
  <p>The issue I am seeing is that although <code>foo.password</code>, the property <strong><em>not</em></strong> declared in the <code>application-dev.properties</code> file <strong><em>is</em></strong> picked up, the override of <code>foo.bar</code> is ignored - I still see the value, <code>baz</code> from <code>application-dev.properties</code> rather than the value, <code>overridden-value</code> from <code>/local/appname/dev/overrides/application.properties</code>.</p>
  
  <p>With the <code>--debug</code> option enabled, I can see the <code>ConfigFileApplicationListener</code> logging that it has loaded both the overrides file (from the filesystem) and the profile-specific file (from the classpath), <strong><em>in that order</em></strong>. </p>
  
  <p>I'm tempted into the perhaps naïve conclusion that because the overrides file is listed first, it is being loaded first then overridden by the 'default' profile-specific file from the classpath, which is listed later. I do appreciate however, that order of listing in the log doesn't necessarily correlate with behaviour. And I have tried varying the order of paths declared on the <code>spring.config.location</code> property, so that <code>classpath:</code> is listed before <code>file:...</code> but this hasn't helped and I't not convinced it would anyway, given that the Spring-boot documentation clearly states that the default properties locations are always searched even if you supply a value for <code>spring.config.location</code>.</p>
  
  <p>The Spring-boot documentation is very specific about the order that properties are resolved for a Spring-boot executable JAR, in <em>descending</em> order of precedence:</p>
  
  <ol>
  <li>Command line arguments.</li>
  <li>Java System properties (<code>System.getProperties()</code>).</li>
  <li>OS environment variables.</li>
  <li>JNDI attributes from <code>java:comp/env</code></li>
  <li>A <code>RandomValuePropertySource</code> that only has properties in <code>random.*</code>.</li>
  <li>Application properties <strong><em>outside</em></strong> of your packaged jar (<code>application.properties</code> including YAML and profile variants).</li>
  <li>Application properties packaged <strong><em>inside</em></strong> your jar (<code>application.properties</code> including YAML and profile variants).</li>
  <li><code>@PropertySource</code> annotations on your <code>@Configuration</code> classes.</li>
  <li>Default properties (specified using <code>SpringApplication.setDefaultProperties</code>).</li>
  </ol>
  
  <p>Take note of lines 6 and 7 - properties <strong><em>outside</em></strong> over properties <strong><em>inside</em></strong> your jar.</p>
  
  <p>What's not stated, as far as I can see, and which may be the source of my confusion/issue, is what happens when you're <strong><em>not</em></strong> using a JAR but an exploded directory (and therefore <code>PropertiesLauncher</code>.)</p>
  
  <p>If the behaviour of an exploded directory were consistent with what's stated for a JAR, I'd expect that the values of properties declared in <code>/local/appname/dev/overrides/application.properties</code> would override any of the same name declared in <code>classpath:application-dev.properties</code>, but this doesn't seem to be the case.</p>
  
  <p>Also noted from the Spring-boot documentation (appendix C.4 on <code>PropertiesLauncher</code>) is mention of the <code>loader.home</code> property, which is described as '... [the] Location of additional properties file, <em>e.g.</em> <code>/opt/app</code> (defaults to <code>${user.dir}</code>)'.</p>
  
  <p>So I tried using <code>loader.home</code> instead of <code>spring.config.location</code>, but to no avail.</p>
  
  <p>(Update: I also tried using <code>loader.config.location</code> and I have two notes: it seems to want a file rather than a directory (so its behaviour is <strong><em>not</em></strong> analogous with <code>spring.config.location</code>), and when I <em>did</em> supply a file path rather than the parent directory, it still didn't help.)</p>
  
  <p>Can anyone spot what I'm doing wrong, or what incorrect assumption(s) I'm making?</p>