0

I have a Spring Boot Application, which have a connection to a MongoDB database.

The connection I can configurate in the server.properties. For the current development I can use the localhost. But for the later server implementation, I need configurate a new server.properties.

How I can change it, if I start the programm, please use the development.server.properties or the consumer.server.properties with different server connection?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Marcel2303
  • 23
  • 6
  • keep in your main properties file a flag. in your code: if flag => use server1 else use server2. You can even implement that as a switch for (unlimited) amount of options – Stultuske May 16 '19 at 12:24
  • 3
    Use profiles in spring boot refer https://www.mkyong.com/spring-boot/spring-boot-profile-based-properties-and-yaml-example/ – Abhijeet May 16 '19 at 12:25
  • 1
    Spring Boot has an entire configuration system specifically to support this. In addition to profiles as mentioned, for credentials (like this), it's best to use [environment variables](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) or a platform-specific connector (like for Cloud Foundry). – chrylis -cautiouslyoptimistic- May 16 '19 at 12:33
  • 1
    It seems you are looking for externalized configuration: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html – AlexLiesenfeld May 16 '19 at 12:47

1 Answers1

2

Option 1: For most real word applications, the properties are not directly packaged with the sources as it can contain sensible info (database password for instance). A simple solution to this, is to put application properties on filesystem and then reference them with the spring.config.location argument

java java -jar demo-0.0.1-SNAPSHOT.jar -Dspring.config.location=/etc/demo/application.properties

this way you keep application.properties away of the packaged jar and you can parse and subsitute values into the application.properties file with your deployment toolchain (like ansible) for each environment accordingly.

some useful doc can be found here: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

Option 2: use profiles. In classpath resources you can have a main application.properties which stores the properties which are common for all environments and then one application-{env}.properties for each environment with specific keys e.g application-dev.properties, application-int.properties, application-prod.properties...

At startup you specify the active profile with then environment variable spring.profiles.active :

java -jar -Dspring.profiles.active=prod demo-0.0.1-SNAPSHOT.jar

slemoine
  • 367
  • 3
  • 8
  • Please note that using profiles is not a good option to use for this kind of problem, because usually you cannot ship production configuration within your jar (such as DB connection strings, passwords, etc.). Externalized configuration is the way to go. – AlexLiesenfeld May 16 '19 at 13:34
  • @AlexLiesenfeld Using profiles is a very good option... Property files aren't only read from the classpath, but also read from default external location or a configurable additional location. Each of those will take the profile into account. So yes using profiles is a very good option. See https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config – M. Deinum May 16 '19 at 13:39
  • Profiles are good to switch between different application configurations (different sets of beans / bean configurations). Can you please explain why do you think it is a good idea to switch between different configuration parameter value sets (i.e. different application.properties files) using profiles? You are also talking about externalized configuration using a profile switch (like described here: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html). – AlexLiesenfeld May 16 '19 at 14:00
  • @AlexLiesenfeld IMO Externalized config is the best way to go in this case (I edited my post to put it in first option), but when I have written the answer I thought that not talking about the profiles things could be a miss. We sometimes use both actually. – slemoine May 16 '19 at 14:11