I have a requirement to split application properties into 2. Some viewable from cloud and some hidden and specified by file on a Rancher environment.
When running locally the default config file successfully honors spring.config.import property which points to a different file.
When fetching the configs from cloud it seams the spring.config.import property is completely ignored and the additional file doesn't get loaded or even checked for.
It there a way to achieve this requirement? Even if different from using the spring.config.import property.
I have upgraded from Spring 2.1.7 to 2.7.7 to be able to use the latest application config loading.
Related
I have several Spring Boot REST services that pull in properties from a Spring Cloud Config server. Let's say the application is called ApplicationName. In that case, the properties files are called ApplicationName.properties, ApplicationName-test.properties, etc. If I update one of those files and trigger the /actuator/refresh endpoint, it doesn't update the properties in the service. It just returns:
[
"config.client.version"
]
indicating it detected a change, but it did not detect the specific value that changed.
Previously, I used Spring Boot 2.3.x and this all worked perfectly. Once I updated to Spring Boot 2.6.x, it stopped working. I just updated to Spring Boot 2.7.1 and it's still not working.
However, if I have properties in a file called application.properties hosted on the same Spring Cloud Config server and I update that one, the refresh endpoint works fine.
I have the Config class annotated with #RefreshScope.
I have the following in my application.yml:
management:
endpoints:
web:
exposure:
include: refresh
endpoint:
refresh:
enabled: true
I have the following in the bootstrap file:
spring.cloud.config.uri=https://spring-cloud-config.domain.com
spring.cloud.config.name=${spring.application.name}
I'm using Spring Boot version 2.7.1 and Spring Cloud Version 2021.0.3.
It seems like there's a setting I'm missing to tell the refresh actuator to check the ${spring.application.name}.properties file in addition to the default application.properties file. Any idea what that setting might be?
Update:
I tried putting the config files in a subdirectory in Bitbucket where the Spring Cloud Config server pulls from. The subdirectory is the name of the application, and the config files inside are named application.properties. The application reads them in fine, but the refresh doesn't work for those either. It seems to only work for files named application.properties that reside in the root directory.
It looks like the following no longer works in the bootstrap.properties file:
spring.cloud.config.name=${spring.application.name}
It allows the properties to load when the service starts, but it does not allow the properties to be refreshed. I was able to get it working by specifying the actual application name:
spring.cloud.config.name=MyApplicationName
I'm using spring-boot-starter 2.3.3.RELEASE version. I'm running my spring cloud configuration server in native profile (looking for configuration files in file system). I added
logging.file = /var/log/config.log in application.properties file. But my application is not logging logs to this file.(All other microservices are logging to this location). Am I missing any additional settings for Spring cloud config server? Thank you so much for your help.
In the spring boot 2.3.3 RELEASE documentation the logging properties that specify where the location should be is indicated using the property:
logging.file.path={path}
The documentation:
https://docs.spring.io/spring-boot/docs/2.3.3.RELEASE/reference/htmlsingle/#boot-features-logging-file-output
This modification from logging.path to logging.file.path appears as a deprecation in Spring Boot 2.2:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.2-Release-Notes#deprecations-in-spring-boot-22
One way to do it with spring-boot application is, setting it from command line argument as default it will dump every thing on console.
logging.file=logs/test.log
Old school but far effective, save path in application.properties
logging.file=logs/test.log
using Spring 2.0.5 with Log4j2
Have found works as expected if I place the file log4j2.xml in the resources folder.
However, have found the log4j2 option of monitorInterval="60" to be super useful as if some production issue can increase logging on some class without a restart. However if log4j2.xml is embedded in the jar of course it cannot be modified. so far the best I have been able to do is use 2 copies of log4j2.xml one in the resources and the other in the folder running the jar from.
I can then run:
java -Dlog4j.configurationFile=log4j2.xml -jar myapp.jar
it seems to work the same if started from the maven spring-boot plugin or from Eclipse.
Have tried a number of things such as setting the classpath, the absolute file name etc. but no luck
My question is how can I remove the log4j2.xml file from the resources folder and only specify it on the command line when starting spring?
I am not entirely clear on your question but I can provide the following information which I hope addresses it:
Log4j 2.12.0 added support for Spring Cloud Config and enhanced the support for Spring Boot. As of that version you can include a file named log4j2.system.properties and place any system properties you want defined there. They will be set before Log4j initializes. So you can specify the full URL to the configuration there if you want instead of the command line. You can also add the definition to a file named log4j2.component.properties.
The support for Spring Cloud Config allows you to place the configuration in your Spring Cloud Config server. See Spring CLoud Config support for more details.
Spring Boot initializes logging at least 3 times. The first is usually because the SpringApplication class declares a Logger so logging is initialized before anything else happens. The configuration for that will use "normal" log4j 2 initialization. After that Spring influences how logging initialization occurs primarily because Spring Boot sets the class path to include the jars inside BOOT-INF/lib directory inside your Spring Boot jar.
By using one of the configuration options I outlined above you can move the logging configuration outside of your application and you should not require a logging configuration in the resources directory. In fact, if you look at the sample Spring Cloud Config Application in Log4j you will see it does not include a configuration file in it.
I have a spring cloud application using config server for fetching configuration. We are using Spring Boot 1.5.4 & Spring Cloud Dalston.SR2.
For deployment purposes we are providing external bootstrap.yml file and specifying its location with spring.cloud.bootstrap.location parameter.
We already had some struggle with the fact that, for couple of properties, service fell back to .jar's bootstrap.yml / application.yml
The only way I could find to solve that, was changing name of external configuration files with spring.config.name and spring.cloud.bootstrap.name. Then, the original names from .jar won't be matched and taken under consideration.
Is there are other way to tackle that?
You could solve that by upgrading to Spring Boot 2.x because they fixed the behavior of spring.config.location (see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide#configuration-location) which also affects spring.cloud.bootstrap.location in the same way
See also that question Different behavior of spring.cloud.bootstrap.location since Spring Boot 2
I have a java service created using JHipster Generator ver 3.4.0 using the monolith approach. How can I use #RefreshScope? Is it just a matter of brining in spring-cloud as dependency and annotating with bean #RefreshScope?
Does the JHipster Configuration UI support updating configuration values?
Is it just a matter of brining in spring-cloud as dependency and annotating with bean #RefreshScope?
You can add spring cloud dependencies partially, so yes. You can generate a microservice application to see how this should be configured properly by taking a look at bootstrap.yml
Does the JHipster Configuration UI support updating configuration values?
I believe you are talking about the JHipster Registry. The purpose of this UI is to show you an aggregated configuration, which is efficiently loaded for some application. This is not really part of spring cloud config. The only 2 ways are filesystem or git repository.
But we are currently working on integrating consul as config solution as well. Consul itself does provide an UI to change config on the fly