我目前在spring boot中有以下配置设置:
application.properties
app.database.host=${DB_HOST}
app.database.port=${DB_PORT}
app.database.name=${DB_NAME}
app.database.user=${DB_USER}
app.database.password=${DB_PASSWORD}
app.database.schema=${DB_SCHEMA:public}
spring.datasource.url=jdbc:postgresql://${app.database.host}:${app.database.port}/${app.database.name}
spring.datasource.username=${app.database.user}
spring.datasource.password=${app.database.password}
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
Run Code Online (Sandbox Code Playgroud)
application-local-dev.properties:
app.database.host=${DB_HOST:localhost}
app.database.port=${DB_PORT:5432}
app.database.name=${DB_NAME:db_name}
app.database.user=${DB_USER:root}
app.database.password=${DB_PASSWORD:root}
app.database.schema=${DB_SCHEMA:public}
Run Code Online (Sandbox Code Playgroud)
application-load-fixtures.properties:
spring.profiles.include=local-dev
spring.profiles.active=load-fixtures,local-dev
app.database.name=${DB_NAME:db_name}_fixtures
Run Code Online (Sandbox Code Playgroud)
这里的想法是,在默认模式下启动应用程序时,如果缺少数据库名称等关键属性,它将无法启动.它们应该通过环境变量传递.
出于开发目的,在设置项目时这是不必要的开销,因为我们有一个具有静态凭据的docker容器,并且我想将它们作为默认值提供.因此,我创建了一个配置文件local-dev,它将使用默认值来连接到我们的docker数据库,并且仍然能够通过环境变量覆盖它们,以防有人需要.直到这里,一切正常.
但是现在,我们还有一个用于将数据夹加载到数据库中的配置文件(删除所有表,重新创建并用数据填充它们).出于显而易见的原因,我想确保无法在任意数据库上执行此操作,因此我创建了一个load-fixtures应继承所有属性的配置文件local-dev并覆盖数据库名称.但是,这种方法似乎是错误的.我可以在spring日志中看到配置文件已正确加载:
2017-11-16 13:32:11.508 INFO 23943 --- [ main] Main:
The following profiles are active: load-fixtures,local-dev
Run Code Online (Sandbox Code Playgroud)
但它仍然使用local-dev配置文件提供的数据库名称.
当我删除该行
app.database.name=${DB_NAME:db_name}
Run Code Online (Sandbox Code Playgroud)
从local-dev配置文件,它的工作原理.
但是,我想要避免的是必须向两者添加新属性,local-dev并且load-fixtures每当我们向项目添加新的配置属性时.
我知道配置文件特定属性优先于非配置文件特定属性.此外,非默认位置属性优先于默认位置的属性.但是在这里,两个配置文件(local-dev和load-fixtures)都在同一个位置,它们也都是特定于配置文件的.
有什么方法可以解决这个问题?
提前致谢!
我最近遇到了相同的问题,并且必须弄清楚Spring应用于几个配置文件特定属性文件的优先级.不幸的是,这没有很好的文档,我没有找到负责该代码的代码的位置.
然而,在经过一些测试和尝试之后,我很确定它的工作方式是这样的(或者至少以类似的方式):可能某种地图用于收集所有不同地方和可能性的所有属性,您可以将它们定义为记录在这里.因此,例如,属性my.value被定义在application.properties并且因此存储在所提到的地图中.然后找到相同的属性作为Java系统属性.由于这种定义属性的方式在PropertySource-order中更高,它将覆盖之前在地图中找到的值.在此之前,根据文档很清楚,Java系统属性将获胜.
但是,当我们在相同的优先级别上找到两个不同的来源,比如两个不同的特定于配置文件的属性文件时,我认为文档不是100%明确的.然而它在24.4中说:
如果指定了多个配置文件,则应用最后获胜策略.例如,spring.profiles.active属性指定的配置文件是在通过SpringApplication API配置的配置文件之后添加的,因此优先.
也许这只是在这里不是最佳的例子,或者我只是不理解它.但我猜"最后胜利"策略也适用于例如中定义的所有配置文件spring.profiles.active.这意味着如果运行java -jar -Dspring.profiles.active=dev,fix application.jar,属性application-fix.properties将覆盖具有相同键的属性的值application-dev.properties.
所以在你的情况下考虑你的应用程序的输出,我猜你指定了类似的东西java -jar -Dspring.profiles.active=load-fixtures,local-dev application.jar.如果我是对的,你只需将其改为java -jar -Dspring.profiles.active=local-dev,load-fixtures application.jar.
| 归档时间: |
|
| 查看次数: |
2231 次 |
| 最近记录: |