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
Related
I was wondering if we can supply a custom attribute (a key to be in application.properties file), I know for sure that -Dserver.port=8080 works, and overrides the property value, but server.port is a spring boot's expected property value.
How about something other than that, for example a jdbc connection string or service name? does -Ddb.service.name=dbservice work?
Yes, any property can be set via system property. You can use -D or -- notation. There are also a variety of property sources Spring Boot uses:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
I see following in Spring Boot application.properties file. What is it doing here:
spring.datasource.password = ${DB_PASSWD:password}
It means try resolving DB_PASSWD property. If found, use it's value. If not, use the default provided value password. In short:
${property:defaultValue}
The property value is looked up from property sources registered in Spring context, see Environment.getProperty() and #PropertySource.
How to get access and customize Freemarker's Configuration object in spring-boot 2.x?
It allows to set square bracket syntax as default option with something like:
Configuration#setTagSyntax(Configuration.SQUARE_BRACKET_TAG_SYNTAX)
which is not possible with any of spring.freemarker.* configuration property.
Also, it should be possible to introduce default imports having access to direct configuration of this object.
It's possible to set any FreeMarker configuration settings with spring.freemarker.settings.<settingName>, like spring.freemarker.settings.tagSyntax = square_bracket. See the JavaDoc of Configuration.setSetting(String, String) for more (https://freemarker.apache.org/docs/api/freemarker/core/Configurable.html#setSetting-java.lang.String-java.lang.String-). This is the method to which Spring delegates the assignments under spring.freemarker.settings; Spring itself doesn't know what "settings" exist or how to parse them.
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.
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?