I have a Spring Boot application written in Kotlin and I would prefer to set the default of a #Value-annotated field like below:
#Value("\${service-clients.logging.exceptions:/}")
private var loggingExceptions: Array<String> = emptyArray()
Is there anything wrong with doing it this way? Most of the resources I found on the web recommend to set the default in the annotation itself. Is there any advantage of doing it that way?
Related
I'd like to set up Flyway properties (org.flywaydb.core.api.configuration.FluentConfiguration) using values from application.yml file. The FluentConfiguration class uses a builder pattern to set up properties.
I see that in Micronaut there is an annotation io.micronaut.context.annotation.ConfigurationBuilder which helps to achieve that. Is there something similar in Spring or other libraries?
Thanks in advance.
Spring Boot supports Kotlin data classes for #ConfigurationProperties.
#ConstructorBinding
#ConfigurationProperties(prefix = "prefix")
data class AppProperties (
val something: String
)
But val and #ConstructorBinding has some limitations. You cannot alias one variable to another. Let's say you're running in Kubernetes and want to capture the hostname, which is given by the env var HOSTNAME. The easiest way to do this is to apply #Value("\${HOSTNAME}:)" to a property, but it only works for a mutable property and without constructor binding.
The Spring Boot GitHub issue tracker says:
STOP!! Please ask questions about how to use something, or to understand why something isn't
working as you expect it to, on Stack Overflow using the spring-boot tag.
So, is this a known limitation or should I create a ticket for them to fix it?
Edit:
Opened https://github.com/spring-projects/spring-boot/issues/25552
#ConfigurationProperties is an alternative to #Value and the two are not designed to be used together. It may work with JavaBean-style binding but that would be by accident rather than by design and it shouldn't be relied upon.
Instead of using #Value to alias something bound via #ConfigurationProperties, it's recommended that you do so via some other means. For example you could use one of the approaches suggested in this answer that Marcos Barbero linked to in the comments on your question. Alternatively, you could take some inspiration from this example in the documentation and use a placeholder in application.properties:
prefix.something=${hostname}
Another option would be to register via META-INF/spring.factories an implementation of EnvironmentPostProcessor that adds a PropertySource to the environment to set up the desired aliasing. For the time being, this is probably the best approach if you want to do something in a reusable library. There's an open issue to remove some of the ceremony that's currently involved.
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.
It is hard to understand but for my application a required format. I have some custom libraries which are included at runtime and so they are not in the spring application context. To get apis from spring boot application I catched required apis and overhand this to my external classes.
To show an example:
HashValueService hashValueService
= (HashValueService) appContext.getBean("hashValueServiceImpl");
ServiceList srvList = new ServiceList();
srvList.setHashValueService(hashValueService);
In this way I'm able to get access to my database, which is in my application context.
I have a lot of properties distributed in the whole application. So I want to use the default application.properties to centralized often used properties in my application, like the keystore.
For that I edited application.properties with this line:
application.keystore=server.jks
But of course the usage of the Spring's #Value does show me a null for that attribute, because this class is not in my application context:
#Value("${application.keystore}")
private String keystore;
Do you have an idea to overhand this properties to this customer libraries? Maybe the creation of a new property file whould help? Thank u a lot.
Majority of Spring magic is done by BeanPostProcessors. Take a good look at them - link.
#Value wiring (and much more) is performed by AutowiredAnnotationBeanPostProcessor, you can use it for your purpose:
AutowiredAnnotationBeanPostProcessor beanPostProcessor =
appContext.getBean(AutowiredAnnotationBeanPostProcessor.class);
ServiceList srvList = new ServiceList();
beanPostProcessor.processInjection(srvList);
After that, your ServiceList should have String keystore field initialized.
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?