Is it possible to use Spring Boot so that all configurations are explicitly in the main class?
For example, is it possible to tell spring-boot to print all autoconfigurations make by #SpringBootApplication so that I can copy paste in my main class?
Or is it possible to copy then from somewhere into the main?
You can have Spring Boot create a report (a list of auto configurations) simply by enabling debug mode in your application.properties file:
debug = true
The auto-configuration report contains information about the classes that Spring Boot found on the classpath and configured automatically. It also shows information about classes that are known to Spring Boot but were not found on the classpath.
And, because you've set debug=true in application.properties or application.yml, so you will see it in your output.
There is no way of doing this. Either you embrace the devil and suffer the consequences latter if you need to personalize something unpredictable by spring boot developers or you don't use it's magic.
Related
I have to change my custom defined spring properties (defined via #ConfigurationProperties beans) during runtime of my Spring Boot application.
Is there any elegant way of doing this using Spring Cloud Config?
I don't want to use an external application.properties in a git repository (as the spring boot application gets shipped to customers and I dont' want to create a git repository for everyone of them).
I just want to access and change the local application.properties (the one in the classpath, located in src/main/resources) file in my Spring container or (if thats not possible) in the Spring Cloud Config Server, which I could embed into my Spring Boot app. Is that possible somehow?
BTW: The goal is to create a visual editor for the customers, so that they can change the application.properties during runtime in their spring boot app.
Spring Boot supports profile based application configuration. Just add application-<profile>.properties file. Then just when running the application select a profile depending on the environment making use of spring.profiles.active.
-Dspring.profiles.active=dev
This will run the application with application-dev.properties file (overriding the default application.properties, i.e you can just leave the common stuff in the default file and change the rest depending on the env)
On a side note, having a repo for configuration is not a must. You could just place them in the class path and give a search-location.
spring:
application:
name: config-server
profiles:
active: native
cloud:
config:
server:
native:
search-locations: classpath:configs/
It actually is possible and in the end quite easy to achieve. It just took me a whole day to get all the information together. Maybe this helps someone:
You basically just need Spring Actuator, but for a certain endpoint, you also need the spring cloud dependency. (to make Post requests to the /env endpoint of Spring Actuator)
To alter your config at runtime, just add the following to your application.properties:
management.endpoints.web.exposure.include: env,refresh
management.endpoint.env.post.enabled: true //this property is only available when spring cloud is added as dependency to your project
If you (like me) don't need the feature of an externalized config, then you also have to add the following (otherwise, your Spring app will not start and throw an error that some config is missing)
spring.cloud.config.enabled: false
Now, if you send a POST request to /actuator/env endpoint with an object in the HTTP body in the form of {"name":"...", "value":"..."} (name is the name of a config property), then your config gets changed. To check that, you can do a GET request to /actuator/env/[name_of_config_property] and see that your config property has changed. No need to restart your app.
Don't forget to secure the /actuator endpoint in your SecurityConfig if you use a custom one.
It seems to me that you neither need the #RefreshScope annotation at your config classes nor the /actuator/refresh endpoint to "apply" the config changes.
Maybe what your looking for could be achieved with Spring cloud config and spring cloud bus. It's explained here: https://cloud.spring.io/spring-cloud-config/reference/html/#_push_notifications_and_spring_cloud_bus
In summary, any change on configuration sent an event to the spring cloud bus and you can then reload app context or configuration with new properties.
I use IntelliJ IDEA, the IntelliSense suggests the usage of assigning jdbc driver in application.properties file as
spring.datasource.driver-class-name=com.microsoft.jdbc.sqlserver.SQLServerDriver
See the image when I typing
But by the answer, that is wrong. It should be
spring.datasource.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
However a web site related to JetBrains seems indicate that using driver-class-name might be correct.
https://youtrack.jetbrains.com/issue/IDEA-202820?_ga=2.207495315.1822682194.1613252382-718343134.1609267918
So I am confused. Which one is right? Is it a bug of IntelliJ IDEA?
Spring Boot supports both formats for properties, and they can be used interchangeably for properties defined by property binding (#ConfigurationProperties beans).
See also Relaxed Binding in the Spring Boot Features documentation:
Spring Boot uses some relaxed rules for binding Environment
properties to #ConfigurationProperties beans, so there does not need
to be an exact match between the Environment property name and the
bean property name. Common examples where this is useful include
dash-separated environment properties (for example, context-path
binds to contextPath), and capitalized environment properties (for
example, PORT binds to port).
In other words, given spring.datasource.driverClassName is defined through a #ConfigurationProperties bean, you can use both spring.datasource.driver-class-name and spring.datasource.driverClassName. The kebab-case form is the recommended form. The relaxed binding was - AFAIK - introduced in Spring Boot 2, so maybe the question you referenced was still at Spring Boot 1.x.
In any case, IntelliJ's autocomplete cannot be wrong in this case, because it uses information contained in the Spring Boot JAR files, generated by Spring Boot tools, specifically for spring.datasource.driver-class-name, this property name is obtained from META-INF/additional-spring-configuration-metadata.json in the spring-boot-autoconfigure JAR file. It is also the property listed in Common Application properties.
The Youtrack issue you listed seems to be an unrelated problem.
I'm creating a Java Spring Boot 2.X application. In my configuration (application.yml), I have added the following property:
logging:
file: ${spring.applicaton.name}.log
This seems to work out of the box. However, I'm curious where the underlying default log configurations reside. Using google I found out that Spring Boot uses logback, but I cannot see a logback-spring.xml file. Also this other question seems to mention log4j2 instead of logback - does that work because they added a dependency on log4j2 (I have not added any dependency except for the sprint boot starter). what I also observed is that the two main logging mechanisms seem to be a rolling file appender and the console logger. Where is this defined?
My question is: where does Spring Boot pick up its default log configuration? I found these configuration files but I'm not sure if they are correct. Their naming convention and syntax is not what I expected. how do you choose a specific logging implementation - by dependencies or by configuration?
The default Logback configuration is stored in:
spring-boot-2.1.1.RELEASE.jar
/org/springframework/boot/logging/logback/base.xml
The default Log4j2 configuration is stored in:
spring-boot-2.1.1.RELEASE.jar
/org/springframework/boot/logging/log4j2/log4j2-file.xml
The default Java Util Logging configuration is stored in:
spring-boot-2.1.1.RELEASE.jar
/org/springframework/boot/logging/java/logging-file.properties
Note: The version of the jar file varies, of course.
Spring defaults to Logback. Read the Spring documentation for how to specify a different implementation and for how to configure it.
I'm currently using an EnvironmentPostProcessor to add my external PropertySource, the code looks like this :
public class ExternalPropertySourceEnvironmentPostProcessor implements EnvironmentPostProcessor
{
private static final String EXTERNAL_PROPERTY_SOURCE_NAME = "ExternalPropertySource";
#Override
public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application)
{
if (environment.acceptsProfiles(Profiles.EXTERNAL_PROPERTY_SOURCE_ENABLED_PROFILE)) {
environment.getPropertySources()
.addLast(new ExternalPropertySource(EXTERNAL_PROPERTY_SOURCE_NAME, new ExternalSource()));
}
}
}
A spring.factories is also used to register this EnvironmentPostProcessor.
This code actually works if the profile is set in the vm environment variables, but if it is added in src/main/resources/application.yml, the profile doesn't seem to be injected yet in the environment and is not returned by the environment.getActiveProfiles(). I've tried using the interface Ordered with the lowest precedence, but it doesn't help.
To add a bit of context around what I'm trying to achieve, this class is in a small library that adds an external property source like a database. Then we can use it in some other spring boot applications. Something like Spring Cloud Config does.
I'd like a clean way to enable or disable this property source depending on the environment where the code runs. I don't mind using something else then profiles or even another way to inject the property source, I just want something clean that doesn't depend on several factors to work.
The main problem in my code right now is that I'm using spring boot's property sources to make my own property source configurable.
UPDATE : I used a Spring Cloud app to debug this, and was confusing the bootstrap context with the normal spring boot context. See my answer below.
Further investigation made me figure out the problem appeared only with a Spring Cloud application.
In fact the breakpoint I had in this code was triggered twice, once after the bootstrap context initialization and once after the spring boot context initialization. I was only debugging the profiles in the first occurence. At that point, only the bootstrap.yml properties are loaded and not the ones from the application.yml file. The second occurence obviously had the profiles from my application.yml file.
My code worked as expected with a vanilla Spring Boot application. As the documentation states :
The Environment has already been prepared with all the usual property
sources that Spring Boot loads by default.
I was confused by the behaviour of my app which seemed to be different from that statement, but it was Spring Cloud's bootstrap that was messing with my debugging.
Since I need a PropertySource that has the highest precedence, I need to add it in the post bootstrap initialization for Spring Cloud apps. I used an init flag on my EnvironmentPostProcessor so it doesn't get executed twice and used the bootstrap.yml on Spring Cloud apps to set the profile.
TL;DR :
With Spring Cloud, an EnvironmentPostProcessor gets called twice: once after the bootstrap init and once after the normal Spring Boot context init. If you need injected properties and are targeting the Spring Cloud's post bootstrap initialization, use the bootstrap.yml instead of application.yml.
I am trying to disable Redis when I am testing with spring boot. I have disabled my configuration but the auto config created a default connection and fails because it can't connect to a non-existent service. For testing I am content to just use a basic in-memory cache or a no-op cache. That doesn't work either. Here is what I have tried:
per this issue I added said configuration to my test app properties
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
But. That gets me a bit further. But ultimately I get a NoSuchBeanDefinitionException redisTemplate - this is because redisReferenceResolver is trying to look that up.
Looking at my debugger right now, the bean it's trying to hydrate is:
org.springframework.data.redis.core.convert.ReferenceResolverImpl which is coming from spring-data-redis:1.8.0.RELEASE which is coming from this dependency: compile('org.springframework.boot:spring-boot-starter-data-redis') . I admit, the bean name is a bit misleading. The type it actually resolves to is not
The only other reference to redis is in our hibernate support.
Can someone explain how to turn this off for testing?
Try excluding this two auto-configuration classes in your test properties file:
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
or
exclude
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
and set: spring.data.redis.repositories.enabled=false
With YAML syntax (& Spring Boot):
spring.autoconfigure:
exclude:
- org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
- org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
If you have SystemEnvironmentPropertySource in you app context you can use environment variable SPRING_AUTOCONFIGURE_EXCLUDE separating items with comma:
SPRING_AUTOCONFIGURE_EXCLUDE=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
Also try #EnableAutoConfiguration(exclude = {...}) on a #TestConfiguration annotated class.
If you dont want to change any files/code, you can also do this with an environment variable:
SPRING_AUTOCONFIGURE_EXCLUDE=org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration