Using Spring Boot 2.6.1, If I have an application.properties file that looks like:
spring.datasource.url="jdbc://blahblah"
I can override that value at runtime with an environment variable named spring.datasource.url and my application will connect to the database specified in the env var.
However, if I have an equivalent application.yaml file, specifying the environment variable that way appears to have no effect.
spring:
datasource:
url: "jdbc://localhost..."
However, if I rename my environment variable to SPRING_DATASOURCE_URL, the override works again. This appears to be consistent across other properties as well (not just the datasource url).
Looking through the docs it wasn't obvious why this should be the case, except that yaml configuration seems like it's generally treated a little different than "normal" properties files.
Is this behaviour expected?
As described in the documentation, you should use the environment variable SPRING_DATASOURCE_URL to set the spring.datasource.url property. I am surprised that spring.datasource.url worked at all when configured as an environment variable and I would not rely on it continuing to do so.
Related
I have specified an external properties file to a Spring Boot app by setting spring.config.additional-location in the SpringApplicationBuilder.
new SpringApplicationBuilder(MyApplication)
.properties(['spring.config.additional-location': myExternalProperties])
.run(myArgs)
This works insofar as it allows me to override properties in the application.properties file using myExternalProperties.
However, myExternalProperties are in turn overridden by any profile-specific properties, e.g. application-myProfile.properties.
I understand this to be consistent with Spring's prioritization of Externalized Configuration, but I want myExternalProperties to override even profile-specific properties.
How can I achieve that order of priority?
I do not control the file name or location of myExternalProperties. This variable is a System property that is preset in the environment.
I have been looking at Profile-specific Properties and in particular this quote.
If you have specified any files in spring.config.location, profile-specific variants of those files are not considered. Use directories in spring.config.location if you want to also use profile-specific properties.
I assume this note applies equally to spring.config.additional-location, but without control over the property file name or location I don't think that helps me.
I'm afraid it cannot be achieved in a non-hacky way.
The docs state:
Profile-specific files always overriding the non-specific ones.
Also:
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.
Could you consider using profile based configuration for myExternalProperties?
You can even use env vars as placeholders.
Hope this helps: Env vars in Spring boot properties
I have an application.yml and application-qa.yml in my resources folder.
I have an external application-qa.yml.
I want the properties in the external application-qa.yml to override the matching ones from the default application.yml and from the internal application-qa.yml, I dont want to override the entire file.
Im adding this VM option (In Intellij): -Dspring.config.additional-location=file:{absolute/path/to/external/ending/with/application-qa.yml}
I also have in env variables (also in Intellij): spring.profiles.active=qa
And for some reason the override doesnt work, I get the value from the internal application-qa.yml instead of the external one.
Tried naming the external file as application.yml, didnt work.
UPDATE:
It does work if I remove application-qa.yml from the end of the path and just give a path to the folder where the file is, but I want to specify a file, I dont want him to take everything thats in the dir.
This is a change in behavior from 1.x to 2.x. The spring.config.location overrides the default instead of adding to it. We need to use spring.config.additional-location to keep the defaults. So if you want to override try spring.config.location instead.
New to spring boot.
While exploring spring boot env variables, came to know that,
env variables can be accessed by ${KeyName} from code.
Got a question like,
Case 1:
In #Configuration files, we are accessing keys in application.properties using #Value(value = "${KeyName}").
So, we are using almost same syntax for accessing env variables and accessing keys in application.properties.
Case 2:
When trying to access the keys in application.properties using system.getEnv("keyname"), I got only null.
Case 3:
Recently worked on configmap in kubernetes with spring boot.
Config file looks like,
spec:
containers:
- name: demo-configconsumercontainer
image: springbootappimage:latest
ports:
- containerPort: 8080
envFrom:
- configMapRef:
name: example-configmap
All the values from configMap is exported as environmental variables and
I am accessing those values by #Value(value = "${KeyName}") and by system.getEnv(KeyName).
My question is, how case 3 is working when case 2 is not.
Is Spring boot made such a way that, it is allowing to access by ${KeyName} and not by system.getEnv(KeyName)? (ie. Case 2)
Could some one clarify my questions here.
Using #Value annotation, you can access a property from many property sources such as in application.properties or an environment variable and few more property sources.
The important point here is ordering of these property sources.
Below is the order of looking up the property in various sources.
Devtools global settings properties on your home directory (~/.spring-boot-devtools.properties when devtools is active).
#TestPropertySource annotations on your tests.
#SpringBootTest#properties annotation attribute on your tests.
Command line arguments.
Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property)
ServletConfig init parameters.
ServletContext init parameters.
JNDI attributes from java:comp/env.
Java System properties (System.getProperties()).
OS environment variables.
A RandomValuePropertySource that only has properties in random.*.
Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
Application properties outside of your packaged jar (application.properties and YAML variants).
Application properties packaged inside your jar (application.properties and YAML variants).
#PropertySource annotations on your #Configuration classes.
Default properties (specified using SpringApplication.setDefaultProperties).
In your case, the property is either declared in environment variable or in application.yaml and hence accessible using #Value annotation.
See the Spring docs:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
Spring includes environment variables as a potential property source, but does not export its properties defined in other ways as environment variables. So it isn't a two way street, which is why case #2 does not work.
Case #3 is a separate reality, just the fact that when K8s runs a container defined in this way with env vars, it makes those vars available in the container environment. Any software system or programming language able to read environment variables will be able to refer to those variables, including Java code. This has nothing to do specifically with Java or Spring...it's just another way to inject environment variables into the runtime environment.
UPDATE: I didn't see #ShaileshPratapwar's answer until I posted my own. Seems our answers are roughly the same, although I think it's good that you know where the list of property sources, and their order of priority, comes from. It's very clearly defined by the Spring docs.
Is there a way in spring-boot YAML file to do the same as in HOCON files where you can have a default and be able to override it with an environment variable like this:
basedir = "/whatever/whatever"
basedir = ${?FORCED_BASEDIR}
In this case in HOCON if you don't define a environment variable named FORCED_BASEDIR then basedir will be "/whatever/whatever" but if you do then the value of basedir will be whatever is defined in the environment variable.
Thanks
So based on webdizz answer below I looked up a little bit and I found a pretty good description in book "Spring Boot in Action". Here is the hierarchy:
There are, in fact, several ways to set properties for a Spring Boot application. Spring
Boot will draw properties from several property sources, including the following:
Command-line arguments
JNDI attributes from java:comp/env
JVM system properties
Operating system environment variables
Randomly generated values for properties prefixed with random.* (referenced
when setting other properties, such as `${random.long})
An application.properties or application.yml file outside of the application
Licensed to Thomas Snead 58 CHAPTER 3 Customizing configuration
An application.properties or application.yml file packaged inside of the
application
Property sources specified by #PropertySource
Default properties
Spring Boot provides means to define variables at many levels and your case is supported, you just need to define variable in following way:
in application.yml:
basedir: "/whatever/whatever"
and in environment:
export BASEDIR = "/another/whatever"
Then in runtime application will use value from environment.
For more details check this out enter link description here.
I seem to be having some funny behaviour with Spring boot on yaml property files im trying to load.
I have a Settings bean that is setup as follows :
#ConfigurationProperties(location = 'config.yml', prefix='settings')
public class Settings {
private String path;
...
}
I've explicitly told spring to look in the config.yml file for property values to bind to the Settings bean. This looks like this:
settings:
path: /yaml_path
This works well, however, I don't seem to be able to override these values from the command line i.e.
java -jar my.jar --settings.path=test
The value that is bound to the settings bean is still /yaml_path but would've expected that the --settings.path=test would override the settings in the yaml.
Interestingly, I've noticed that if i take comment out the path setting from the yaml file, the commandline argument value of test comes through.
Additionally, I've also noticed that if i change my config file from config.yml to application.yml and remove the 'location' attribute from the configuration properties file this gives me the desired desired behaviour, but means that I can't have multiple application.yml files in the classpath as it breaks my multi module application which has configuration files throughout.
Ideal world I would like be able to have modules read configuration from yaml files that contain safe values for that module (i.e. module.yml) and be able to override these values from the commandline if needed. Has anyone figured out how to get commandline arguments passed into the beans this way?
I have created a project on git hub to show case the issue
https://github.com/vcetinick/spring-boot-yaml-test
Running the application displays logging information about what settings are applied. i.e.
java -jar spring-boot-yaml-test-0.0.1-SNAPSHOT.jar --config.path=/test
should override the settings, however, the default /var/tmp is displayed
additionally, when using the application.yml configuration
java -jar spring-boot-yaml-test-0.0.1-SNAPSHOT.jar --app.path=/test
seems to behave as expected where the command line argument overrides the value but only works because its value is defined in the application.yml file.
Looks like the locations attribute is working as designed, however, seems to be at odds with the standard configuration paradigm setup by spring boot (https://github.com/spring-projects/spring-boot/issues/5111). It is meant to override the settings. It looks like this this feature may be removed in a future release of spring boot anyway (https://github.com/spring-projects/spring-boot/issues/5129)