I'm using Spring Boot and several profiles (dev, test, prod). I've configured my application settings now in application-dev.properties, application-test.properties, and application-prod.properties.

The above files are all located in src/main/resources, which is not ideal, since now my application will be deployed to production with production configurations, but (while not active) also with the configuration for test and dev.

What is the correct way in Spring Boot to organise these files? I can imagine putting application-test.properties in src/test/resources, but what about the application-dev.properties file?

CodePudding user response：

I understand your question, but you shouldn't be too much concerned about shipping to production with a packaged profile properties that won't be loaded at runtime.

It is how SpringBoot works and any other framework (Quarkus, ...), your application-*.properties files are meant to live there (src/main/resources). If your -test.properties is not referring a real environment but solely useful for your UTs, then it can be moved to src/test/resources.

CodePudding user response：

Spring Boot, out-of-the-box, supports various locations for storing your application-<profile>.[properties|yaml] files. As explained in this section of the documentation.

1. From the classpath
   • The classpath root
   • The classpath /config package
2. From the current directory
   • The current directory
   • The /config subdirectory in the current directory
   • Immediate child directories of the /config subdirectory

You could even override/add to those directories with specifying the spring.config.location property at runtime to your application.

So you don't need to ship them with your application.

Next you also have a myriad of options on how to provide properties for configuration to your Spring Boot application. Files is just one of them, and is explained in this section of the documentation. If you add Spring Cloud Config you even get more options as you could also use a centralized configuration server next to the already existing options!.

So instead of providing a file for each environment you could also specify environment variables or provide the information at startup as program attributes. Finally, as deduced from the file location, you could also place the application-<profile>.[properties|yaml] next to the jar file instead of inside it and it would be picked up as well. Drawback of the latter is that you need to ship those files next to the jar.

Commonly used, for other then local use, is a config server (or even a key vault) to centralize the configuration.

CodePudding user response：

An alternate solution would be to store Dev, QA, Prod environment properties together in a single yaml file like below and can activate the respective environment profile by configuring spring.profiles.active property. In this way can at least overcome multiple config files.

application.yml

logging:
  level:
    org.springframework: ERROR
    com.mkyong: ERROR

spring:
  profiles:
    active: dev
  main:
    banner-mode: off

---

spring:
  profiles: dev
server:
  cluster:
    - ip: 127.0.0.1
      path: /dev1
    - ip: 127.0.0.2
      path: /dev2
    - ip: 127.0.0.3
      path: /dev3

---

spring:
  profiles: prod
server:
  cluster:
    - ip: 192.168.0.1
      path: /app1
    - ip: 192.168.0.2
      path: /app2
    - ip: 192.168.0.3
      path: /app3