I'm using Spring Boot 1.3.6 and Spring Session and Redis as the Session store. I need to be able to set the redisNamespace for the application a runtime, and not hard-code it in the code. That means I cannot use #EnableRedisHttpSession since that is not something I can set via the applaction.yml file.
I've updated Spring Session to 1.2.1.RELEASE to get the support I need, but I cannot seem to get the system to configure the namespace via configuration. I tried using a SPEL in the #EnableRedisHttpSession(redisNamespace) call, but that doesn't work. I tried to have the RedisHttpSessionConfiguration injected via Autowired to set it as well, and that seemed to have been ignored. There was also another reference in another SO post about using spring.session.redis.namespace as a property in application.yml but that doesn't work.
Any suggestions/tips would be greatly appreciated!
Declaring spring.redis.namespace per the documentation is not enough.
After setting #EnableRedisHttpSession() to #EnableRedisHttpSession(redisNamespace = "${spring.redis.namespace}") it worked.
Per the normal functionality to externalise configuration you can use system environment variables as well, instead of spring.redis.namespace.
Note: In this case spring.redis.namespace corresponds to the application.yaml file that looks like:
spring:
redis:
namespace: ${REDIS_NAMESPACE:foobar}
I simply put a -Dspring.session.redis.namespace=myKeyName to VM arguments.
and it is working fine.
and I'm using spring boot v1.3.5.RELEASE and spring session 1.2.0.RELEASE.
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.
Currently spring boot seems to support only classpath based logging configuration.
It also ignores any configuration passed as vm argument as follows.
-Dlog4j.configurationFile=/opt/xyz/log4j2-prod.xml
How can we have different log4j2 configuration based on different environment, considering classpath for all environment remains same.
What about set the properties: logging.config=classpath:log4j2-dev-spring.xml in each application-{profile}.properties that you have. Can use like this too: logging.config=${ENV_VAR}
You should use the following param
-Dlogging.config='/path/to/log4j2.xml'
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'm trying to externalize logging configuration. However, any configuration I establish (e.g. -Dlogback.configurationFile=...) is wiped out the moment I call SpringApplication.run(). Is there a way to prevent this?
Try 'logging.config' (or use one of the the conventional locations, e.g. 'classpath:/logback.xml'). Docs here: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#boot-features-custom-log-configuration.
I'm using Spring 2.5.6. I have a bean whose properties are being assign from a property file via a PropertyPlaceholderConfigurer. I'm wondering whether its possible to have the property of the bean updated when the property file is modified. There would be for example some periodic process which checks the last modified date of the property file, and if it has changed, reload the bean.
I'm wondering if there is already something that satisfies my requirements. If not, what would be the best approach to solving this problem?
Thanks for your help.
Might also look into useing Spring's PropertyOverrideConfigurer. Could re-read the properties and re-apply it in some polling/schedular bean.
It does depend on how the actual configured beans use these properties. They might, for example, indirectly cache them somewhere themself.
If you want dynamic properties at runtime, perhaps another way to do it is JMX.
One way to do this is to embed a groovy console in your application. Here's some instructions. They were very simple to do, btw - took me very little time even though I'm not that familiar with groovy.
Once you do that you can simply go into the console and change values inside the live application on the fly.
You might try to use a custom scope for the bean that recreates beans on changes of the properties file. See my more extensive answer here.
Spring Cloud Config has facilities to change configuration properties at runtime via the Spring Cloud Bus and using a Cloud Config Server. The configuration or .properties or .yml files are "externalized" from the Spring app and instead retrieved from a Spring Cloud Config Server that the app connects to on startup. That Cloud Config Server retrieves the appropriate configuration .properties or .yml files from a GIT repo (there are other storage solutions, but GIT is the most common). You can then change configuration at runtime by changing the contents of the GIT repo's configuration files--The Cloud Config Server broadcasts the changes to any Client Spring applications via the Spring Cloud Bus, and those applications' configuration is updated without needing a restart of the app. You can find a working simple example here: https://github.com/ldojo/spring-cloud-config-examples