Hi Scott! Yes this is supported.
Simply provide either a PropertySource (if you are guaranteed to only have a single location of that property file) or a PropertySourceProvider (if you have multiple property files of a kind). In those classes use System.getEnv() to resolve the 'environment' and take that setting to pick up the right files. Remember that all PropertySources have an ordinal. The higher the ordinal, the more important that information. So you could simply provide another PropertySource which takes an external file and use a higher ordinal for that one. hth LieGrue, strub On Monday, 18 July 2016, 10:58, Scott Taylor <[email protected]> wrote: > > >I apologize if this question has been asked already, but my search attempts >failed to provide the information I was looking for. I have the following >use case: > >I am producing an executable jar file that will run in three different >environments (dev, staging, production). My application contains three >different property files, one for each environment. Eg. dev.properties, >staging.properties, production.properties. These properties are checked >into GitHub and all three are included together in the executable jar file. >When starting up the jar file I will set either an environment variable or >system property to indicate which environment the jar is running in. Eg. >-Denvironment=staging. And finally I would like to be able to create a >property file on the local file system that overrides the bundled ones or >contains property settings that are not allowed to be checked into GitHub >for security reasons. > >Is this use case supported by Tamaya? Is there a recommend way to implement >this using Tamaya? > >Any help greatly appreciated, >Scott > > >
