I am using Spring Data ElasticSearch repository and I like to give a default index name for production and another one for testing
Here the application.properties for production:
spring.data.elasticsearch.cluster-name=elasticsearch
spring.data.elasticsearch.cluster-nodes=localhost:9300
spring.data.elasticsearch.repositories.enabled=true
Here the configuration application-test.properties
spring.data.elasticsearch.cluster-name=elasticsearch
spring.data.elasticsearch.cluster-nodes=localhost:9300
elasticsearch.index.name=registry-test
spring.data.elasticsearch.repositories.enabled=true
The elasticsearch.index.name does not seem to be taken in account. What is the right setting in the properties if I am using Spring Boot autoconfiguration? I cannot find any info in the Spring documentation.
Thanks for your help.
This is full list of properties Spring boot understands. You'll need to scroll down to find Elasticsearch related properties. Your property is not listed.
There is one, which may help you:
spring.data.elasticsearch.properties.*= # Additional properties used to configure the client.
But I don't know how it's working. So I guess best option for you would be to create Elasticsearch beans explicitly and not rely on auto-configuration.
Related
I learning Spring boot and found that in some examples use the same properties with the prefix spring.jpa.properties while other do it without prefix.
For instance:
The article explains second level cahche https://www.baeldung.com/hibernate-second-level-cache and autor shows example of needed properties ( example on autor's gitHub):
hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
But it did not work for me, and I spent few hours loking for the reason, but then i noticed, someone use prefix spring.jpa.properties. to get it working (Exact moment from video lesson):
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
Which perfectly worked for me.
So my questions are:
why are they working in different way?
how to understand which properties in which cases requires this prefix?
is it probably something related to my project settings OR Spring Boot version?
any other suggestions are appreciated :)
Thank you in advance!
There are a couple of things in play here. First the tutorial you use is using plain Spring not Spring Boot. Which means a manually configured EntityManagerFactory on which you directly can set the provider specific properties. Like hibernate.cache.use_second_level_cache.
As you decided to use Spring Boot you don't have a manually configured EntityManagerFactory (although you could!). Which means you are using an autoconfigured EntityManagerFactory. Properties for this reside in the spring.jpa namespace for properties.
As it isn't feasible to specify properties for each and every extension for Hibernate (or other JPA providers) only some commonly used ones are exposed like spring.jpa.generate-ddl and a few provider specific ones in the spring.jpa.hibernate namespace. However to set all the other properties in an autoconfigured way there needed to be something else. Hence the spring.jpa.properties prefix. Anything specified in there will be passed on as is (without the said prefix ofcourse) to the EntityManagerFactory for configuration.
I have a Camel Spring Boot application where I am printing the value of a property which is set using Spring Cloud Config Server (via Git commit id plugin). The issue is that the value of the property in Camel application is not updated once the value is committed to Git. I have to restart the Camel application which fails the purpose of Spring Cloud Config server. Please note that we are using Git file system in our local machine.
The name of the properties file is CamelSpringBootSample-dev.properties.
As soon as I commit, the config server publishes the updated value at the endpoint on refresh:
http://localhost:8888/CamelSpringBootSample/dev
I have also made the Camel application end point available at:
http://localhost:8181/actuator/env
Here the value of the property is not updated on refresh. However, if I restart the Camel application, the value is reflecting.
The source code for all the three projects are uploaded in github.com.
The config server: https://github.com/sreejeshraj/config-server
The Camel client project (which uses the config server to configure itself): https://github.com/sreejeshraj/camel-config-server
Please do not get misled by the repository name camel-config-server. This is the client of config server, but I accidentally named it incorrectly, apologies.
The local git repository where the configuration properties are stored: https://github.com/sreejeshraj/Git-Config
Please note that I have used the annotation #RefreshScope in my Spring bean component class.
Can you please help me with this? Thanks in advance.
You have to set:
management.endpoints.web.exposure.include=refresh
in bootstrap.properties or bootstrap.yml.
and trigger the /actuator/refresh endpoint.
See #RefreshScope and /refresh not working
Note that as said in the comments, Camel does not update its values when a Spring beans is refreshed and there is no plan to implement this feature. (https://issues.apache.org/jira/browse/CAMEL-13892). You probably could find a solution through Spring Cloud Bus.
As #ortomala-lokni already pointed out, you need to refresh your configuration consumers after an update happened.
If you want a centralized solution for this task (for refreshing many components automatically), take a look at Spring Cloud Bus.
This page gives a quite good overview about the subject.
I had a situation where I had both application.properties and bootstrap.properties file in my client. I that case you should specify spring.application.name and spring.cloud.config.server.git.uri inside bootstrap.yml. I didn't refresh properties having spring.application.name inside applicaiton.properties.
I am setup to use logback with my SpringBoot application and everything is running fine and dandy.
I noticed a property called logging.path in the application.properties file which sets the value for ${LOG_PATH} in logback.xml. How does it do it?
I went through the SpringBoot logging documentation.
Any documentation I could find on property placeholder configurer
Yet I don't understand how logging.path could pass the value for ${LOG_PATH}. Though not a killer issue, I would like to know how this mapping is made.
The magic is spring will transfter logging.path into System propeties LOG_PATH.
Description from spring doc:
To help with the customization some other properties are transferred from the Spring Environment to System properties:
And it also says:
All the logging systems supported can consult System properties when parsing their configuration files. See the default configurations in spring-boot.jar for examples.
Details:
https://docs.spring.io/spring-boot/docs/1.5.6.RELEASE/reference/htmlsingle/#boot-features-custom-log-configuration
For more recent versions of Spring Boot, such as 2.5.x, the logging.file.path maps to LOG_PATH.
We are leveraging Spring Cloud Config and Spring Cloud Config Vault. We would like to know if there is a way to "bootstrap the bootstrap", ie we want spring cloud config server to be hit and then pull properties from that to leverage in our vault configuration. We looked at order, but it didn't appear to work, and I assume it is because of the post processing order, but I was hoping I might be missing something.
TL;DR
It doesn't work.
Explanation
What Spring Cloud does with its bootstrap context, is setting up an application context that contains a set of PropertySources initialized from Spring beans. The bootstrap context is used then as parent context for the actual context created by Spring Boot. A property lookup looks for properties in its own context and within the parent context.
Configuration properties are initialized very early in the startup process and they use properties from the current Environment. At the time ConfigurationProperties beans are initialized, the Environment does not yet contain any remote PropertySources.
The only option I see here (except creating a bootstrap-bootstrap-context) is using the Spring Cloud Config client within your main class and contribute Vault properties before any Spring context is built.
Probably you can, but it requires PropertySourceBootstrapConfiguration#initialize() method overriding. You can't disable bean PropertySourceBootstrapConfiguration, but you can disable it's initialize method by using applicationContext.getBeanFactory().getBean(PropertySourceBootstrapConfiguration.class).setPropertySourceLocators(new ArrayList<>()) in CustomPropertySourceBootstrapConfiguration (to avoid obsolete external property sources calls).
In your CustomPropertySourceBootstrapConfiguration#initialize method you can retrieve properties from config-server and then customize your vaultPropertySourceLocator by inserting generated in config-server secretId of token.
Don't forget to add your CustomPropertySourceBootstrapConfiguration to spring.factories.
So, it's not easy but it is possible.
We created the custom datasource using EnvironmentPostProcessor which will get called before autoconfigure beans
https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.application.customize-the-environment-or-application-context
I am configuring Consul with SpringBoot and found a documentation here. Even browsed other resources, no more additional configs or scenarios found.
Therefore, I am curious whether only those configurations are available when springboot app is integrated with consul. I would like to deep dive and Can anyone let me know any other properties available ?
These are the properties available.
These are used in
org.springframework.cloud.consul.config.ConsulConfigProperties, org.springframework.cloud.consul.discovery.ConsulDiscoveryProperties.
Best place to see which property is being used where is to see AutoConfiguration of any module. For example for Mongo check MongoAutoConfiguration and MongoDataAutoConfiguration. Similarly, for consul check ConsulAutoConfiguration
This page will provide configuration properties
https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html
In addition, you can see the config properties in your IDE itself. If you are using IntelliJ or STS/Eclipse, go to application.yml file, you can view and see the configurations available by pressing Ctrl + space . It will give suggestions.