I have different profiles based on environment wise and needs to load it. How i can achieve and also how to pass program arguments for Quarkus main application to take dev profile(spring.config.location=classpath:/config/dev/application.yml)
Is there a way to load databse configuration while starting #QuarkusMain. I have configured all the database configurations into one class and how this class can be load in main. Please suggest on this.
Quarkus 1.13 (and later), supports profile aware application.properties. Just name your file application-{profile}.properties and activate it with -Dquarkus.profile={profile}
If you want to load specific files, you can also use quarkus.config.locations. This is backed by SmallRye Config. Please check additional documentation here: https://smallrye.io/docs/smallrye-config/main/config/config.html
Related
In quarkus the config is stored inside an application.properties file.
You can have multiple application-{profile}.properties files. {profile} is the name of the profile you want it to be.
When started with java -jar <pathToJar> -Dquarkus.profile=PROFILE_ONE the file application-PROFILEONE.properties is used. During startup of the app you can read that quarkus is using the PROFILE_ONE profile.
When started with java -jar <pathToJar> -Dsmallrye.config.profile=PROFILE_ONE the file application-PROFILEONE.properties is used. During startup of the app you can read that quarkus is using the PROD profile.
What exactly is the difference between both? Is it better to use smallrye.config.profile so that quarkus is still using the PROD profile? Is the PROD profile faster?
Thanks!
That is actually a bug. Internally, both use the same profile, but the log is reporting a different one when you use smallrye.config.profile, because it is only checking for quarkus.profile and then it defaults to prod (later in the code the actual profile is checked and used the correct one).
The message needs to be fixed. I'll look into it.
In Quarkus, We have properties file inside project itself called application.properties.
Is there any Quarkus way to define external properties file in my use case like i am developing a mail sender and i want to add recipients in future.
Is it possible to give application.properties outside at local and inject it at runtime?
You can add a configuration file in your application working directory under config/application.properties : https://quarkus.io/guides/config#overriding-properties-at-runtime
There is ongoing discussion to have more runtime configuration capabilities here: https://github.com/quarkusio/quarkus/issues/1218
You can achieve this by keeping .properties (or .yaml) in Spring Cloud Config Server.
It's really easy to set it up. It's is well documented in following link (official documentation):
Quarkus - Reading properties from Spring Cloud Config Server
As loïc says, you can follow the convention and create a config/application.properties. You can also use the property quarkus.config.locations to specify additional config locations. It can be defined at runtime like below
java -Dquarkus.config.locations=app-config/config.properties -jar my-app.jar
I'm having issues with a custom Spring Boot starter. How can a starter cause a profile to be included and pull related configuration from a config server?
Perhaps my use case is unique, because I haven't found any helpful information online. I'm working in an enterprise environment and this starter is for use by my team, so we're able to control some things (like profile names) that perhaps wouldn't make sense in the open source world.
Here is the scenario: We have a Spring Cloud Config Server running to provide configuration. Across our Spring Boot projects, we have standardized on certain profile names such as "prod" and "nonprod" to control configuration in our different environments. I am trying to create a starter to provide reusable functionality. For example purposes, let's say I'm creating a starter that provides an interface to an appliance that performs cryptographic work for us. This starter will need the IP address of the appliance and various other configuration which differs between production and non-production.
Within the config repo, I will have files such as application.yml, application-nonprod.yml, application-nonprodEncryption.yml, etc.
My goal is to have the custom encryption starter automatically include the nonprodEncryption profile when that starter is included in an application. By doing this, apps which don't need encryption do not load the encryption related properties.
Here are my experimental findings so far:
Within an application's bootstrap.yml, I can put a block such as
spring.profiles: nonprod
spring:
profiles:
include:
- nonprodEncryption
and that produces the desired result (i.e. the application-nonprodEncryption.yml file is loaded from the config server and used), but this is an undesirable solution as every app that uses my custom starter would need to include this boilerplate configuration.
When I move the above configuration to the starter's bootstrap.yml, it seems to have no effect.
When I move the above configuration to the starter's application.yml, it seems to be applied (i.e. it shows up in the The following profiles are active: list), but it is too late in the lifecycle to cause the appropriate configuration to be pulled from the config server.
Other things I've considered:
Why not just put all of the configuration into the main profile config file (e.g. application-nonprod.yml)? From a separation of concerns and maintenance standpoint, I'd like to keep configuration for individual starters isolated from each other. Also, some configuration data is more sensitive than other config data, so I don't like the idea of exposing all of the configuration to all apps, since many apps won't need some of the more sensitive configuration. Yes, they could get to it, but why load it into their memory if they don't need it?
Why not just specify the extra profiles when we launch the app? These apps will be running on a cloud platform. The platform will specify either "prod" or "nonprod" as the profile based on which tier the app is running in. I want to manage that at the platform level rather than the app level, so I want the list of profiles provided at app launch to be uniform across all apps (add adding, for example, nonprodEncryption to the list just gets me into the same situation as above - all apps would have all of the configuration, so I might as well just put it all in a single file).
We are currently using Spring Boot 1.5.10.
Any thoughts on how to achieve what I'm trying to do?
I finally found a solution (in case anyone else finds themselves in the same spot).
Step 1: Add a configuration class like this to your starter:
package com.company.bootstrap;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.annotation.Profile;
#Configuration
#Profile("nonprod")
public class BootstrapNonprod {
public BootstrapNonprod(ConfigurableApplicationContext ctx) {
ctx.getEnvironment().addActiveProfile("nonprodEncryption");
}
}
This will conditionally add a profile. In this example, whenever the "nonprod" profile is active, this class will add the "nonprodEncryption" profile.
Step 2: In your starter's spring.factories file, add a line such as this:
org.springframework.cloud.bootstrap.BootstrapConfiguration=com.company.bootstrap.BootstrapNonprod
It seems like it is just that simple.
I currently have the following config setup in 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
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}
application-load-fixtures.properties:
spring.profiles.include=local-dev
spring.profiles.active=load-fixtures,local-dev
app.database.name=${DB_NAME:db_name}_fixtures
The idea here is that when starting the app in default mode, it will fail to boot when critical properties like database name are missing.
They should be passed via environment variables.
For development purposes, this is unnecessary overhead when setting up the project because we have a docker container with static credentials and I'd like to provide them as defaults. Therefore, I created a profile local-dev that will use default values to be able to connect to our docker database and still have the ability to override them via environment variables in case someone needs to.
Until here, everything works fine.
But now, we also have a profile that is used to load fixtures into the database (drop all tables, recreate and fill them with data).
For obvious reasons, I want to ensure that this cannot be done on an arbitrary database, so I created a profile load-fixtures that should inherit all properties from local-dev and override the database name. However, this approach seems to be wrong. I can see in the spring log that the profiles are loaded properly:
2017-11-16 13:32:11.508 INFO 23943 --- [ main] Main:
The following profiles are active: load-fixtures,local-dev
But it still uses the database name provided by the local-dev profile.
When I remove the line
app.database.name=${DB_NAME:db_name}
from the local-dev config file, it works.
However, what I want to avoid is having to add new properties to both, local-dev and load-fixtures, whenever we add a new configuration property to the project.
I understand that profile specific properties take precedence over non-profile specific ones. And also that non-default location properties take precedence over properties from the default locations. But here, both profiles (local-dev and load-fixtures) are in the same location, and they are also both profile specific.
What are proper ways to go about this problem?
Thanks in advance!
I recently came across quite the same problem and had to figure out which precedence Spring applies to several profile specific property files. Unfortunately this is not well documented and I did not find the location of the code that is responsible for that.
However after some tests and tries I'm pretty sure it works like this (or at least in a similar way):
Probably some kind of map is used to gather up all properties of all the different places and possibilites where you could define them like documented here. So for example a property my.value is defined in application.properties and so stored in the mentioned map. Then the same property is found as Java system property. Since this way of defining a property is higher in the PropertySource-order it will override the value found before in the map. Until here it is clear according to the documentation that the Java system property will win.
But as we come to two different sources on the same precedence level like two different profile specific property files the documentation is not a 100% clear in my opinion. However it says in 24.4:
If several profiles are specified, a last-wins strategy applies. For example, profiles specified by the spring.profiles.active property are added after those configured through the SpringApplication API and therefore take precedence.
Maybe it is just the example that is not optimal here or I just do not understand it correctly. But I guess the "last-wins" strategy also applies to all profiles defined for example in spring.profiles.active. That means if you run java -jar -Dspring.profiles.active=dev,fix application.jar, the properties in application-fix.properties will overwrite the values of properties having the same key in application-dev.properties.
So in your case considering the output of your application I guess you specified something like java -jar -Dspring.profiles.active=load-fixtures,local-dev application.jar. If I was correct, you would just have to change that into java -jar -Dspring.profiles.active=local-dev,load-fixtures application.jar.
We've multi module SpringMVC project, each having separate applicationContext.xml, currently we have to edit the applicationContext.xml files for every module before we deploy. It's painful and error prone. Is there a way to have only one property file that all other will contexts look at. Then we only have to edit one property file before we build and deploy. Thanks in advance.
It sounds like you should be using Spring's Profile support, which allows you to specify separate properties files per environment. You can pass the application an environment property spring.profiles.active and set it to say, "dev", "test", or "prod".
If you're using Spring Boot it can then automatically pick up distinct configuration per environment, application.dev.properties or application.prod.properties which will overwrite the standard application.properties with environment specific configuration.
If not using Spring Boot you would just have configure your Properties Sources per profile.
This is most definitely the preferred approach to changing configuration files at build or deploy time.
Reference: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-environment