Spring Boot allows a lot of ways to configure your application and to overwrite existing configuration properties (https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/reference/html/boot-features-external-config.html)
In our application I guess we use every single feature described there (at least twice). Now starting the application (of corse in a container in kubernetes) I have discovered some misconfiguration.
Is there a way to find out where a configuration property comes from? Something providing some output like
property "foo":
-> from PropertySource classpath://myFooSource.proproperties = baa
-> from application.properties = baz
-> from environment variable FOO = bar
-> final from command line --foo=ping
I would say that Spring Boot Actuator /env endpoint is what you are looking for, given that it returns the current environment properties in your application. You can enable it with management.endpoint.shutdown.enabled=true. You can check more details in the reference documentation at https://docs.spring.io/spring-boot/docs/current/actuator-api/htmlsingle/#env.
Related
When using Spring Cloud config server, I have observed the below behavior. Please let me know, if my hypothesis is correct regarding the behavior.
If the application-${env}.yaml/properties have the server.port property set, I cannot override the value, even by passing -Dserver.port
If I do not inherit the property defined in the spring cloud config, then I will be able to provide the value inside the application.yaml/property of the application
If the property is defined inside the application's application.property/yaml, I can override the value from the command line by passing the -Dserver.port option.
Is my assumptions right based on the above behavior.
Yes, spring cloud config value can't overwrite by default . We can change to override with property pring.cloud.config.allowOverride=true
https://cloud.spring.io/spring-cloud-static/spring-cloud.html#overriding-bootstrap-properties
I run a Spring Boot application as a .jar file which partly takes its properties from application.yml residing inside the jar while the other part of properties is being provided from another application.yml residing outside the jar. Some of the properties from the outside overwrite the properties from the inside. In order to test whether the properties were overwritten properly I would like to see the currently active ones. Is that achieveable at all out of the box? Or is the only solution to extend my application by property output logic?
If you add Spring Boot Actuator to your dependencies, you can view a lot of configuration and other info at actuator endpoints. You can view properties at /configprops endpoint.
At least as of spring boot 2.0 actuator/env will return the list of all properties per propertySources in order of their precedence, ie. if a property is redefined in >1 sources then the 1st occurrence reading from the top is the one that is active.
For a single property actuator/env/<property-name> will return the effective value and in which source it's defined
{
"property": {
"source": "applicationConfig: [file:../application-tom.properties]",
"value": "DEBUG"
},
...
}
Note: I dont know if this would reflect any changes that might happen when programmatically modifying the spring context. But that is smth. one should not do anyhow.
I have a requirement where I need my custom application properties to act as aliases to various common application properties that spring provides for different packages.
Example:
Whenever I set a value to the application property foo.host, it should set the value for spring.rabbit.host property.
Similarly setting the value for foo.port should set the value for spring.rabbitmq.port.
Can this be achieved?
It can, you can add these to your application.properties:
spring.rabbit.host=${foo.host}
spring.rabbit.port=${foo.port}
However, if you still provide spring.rabbit.host via system properties, as an environment variable or as direct argument then it will take precedence over foo config.
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)
At the project with Spring Boot we use application.properties but need to configure some of these properties (like port number of logging level) based on an external configuration. We access the configuration via API so it is known only at runtime.
Is there a way to override or set some Spring properties at runtime (for example using a bean) and if yes how can this be achieved?
You could do this with Spring Cloud Config
Just for the purpose of illustration, here's a relatively quick way to see dynamic property overrides at runtime:
First, for your bean to be able to pick up changed properties, you need to annotate it with
#RefreshScope
Add the spring cloud dependency to your spring boot app, eg for gradle
compile group: 'org.springframework.cloud', name: 'spring-cloud-starter', version: '1.1.1.RELEASE'
( NB You also need the spring boot actuator dependency.)
With the app running, you can view your current config at eg
http://localhost:8080/env
eg if you have a property 'my.property' in application.properties, you'll see something like:
"applicationConfig: [classpath:/application.properties]": {
"my.property": "value1",
etc
To change the value, POST my.property=value2 to /env as application/x-www-form-urlencoded
eg
curl -X POST http://localhost:8080 -d my.property=value2
GET /env again and you'll see the new value appears under the "manager" section
To apply the changed properties, do an empty POST to /refresh. Now your bean will have the new value.
Could you use system properties to pass in the variable? If you configure the PropertyPlaceholderConfigurer you can set the precedence of system properties vs file properties.
For example, something like:
#Bean public PropertyPlaceholderConfigurer placeHolderConfigurer() {
PropertyPlaceholderConfigurer props = new PropertyPlaceholderConfigurer()
props.setSystemPropertiesMode( PropertyPlaceholderConfigurer.SYSTEM_PROPERTIES_MODE_OVERRIDE )
props.setLocations(new
PathMatchingResourcePatternResolver().getResources("classpath:/**.properties"));
props
}
The above would load your .properties file, but we set the priority to be system variables first, so if you set a system variable that will override the same variable in the config.
Alternatively, looking at the docs, Spring recommends defining a search order in your Environment:
[PropertyPlaceholderConfigurer is still appropriate for use when]
existing configuration makes use of the "systemPropertiesMode" and/or "systemPropertiesModeName" properties. Users are encouraged to
move away from using these settings, and rather configure property
source search order through the container's Environment; however,
exact preservation of functionality may be maintained by continuing to
use PropertyPlaceholderConfigurer.
Hopefully one of the above should sort out what you need?