I was guessing that PropertySourceProvider was the way to go. Thanks for the help!
/Scott On Mon, Jul 18, 2016 at 11:19 AM, Mark Struberg <[email protected]> wrote: > 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 > > > > > > >
