in a Spring Boot application, I am worried about AutoConfigurations also being triggered by transitive dependencies.
Specific autoconfigurations can be switched off as described here Disable Spring Boot AutoConfiguration for transitive dependencies
But how can I know which AutoConfigurations have been activated? There does not seem to be a consistent logging of activations on startup. I just noticed VelocityAutoConfiguration has been activated in my application, I can disable that, but it makes me worried about other autoconfigurations being activated without my knowledge and intent.
Definitely pay attention to those transitive dependencies.
There's about 5 or more different ways you can enable or view the #EnableAutoConfiguration report. The report will show you:
what's enabled
what's disabled
what's excluded
configurations that are unconditional
As an application argument
--debug
As a VM argument
-Ddebug
As an environment variable
export DEBUG=true // UNIX based
set DEBUG=true // Windows based
By adding a property to your application.properties
debug=true
Adjusting the log level in your application.properties
logging.level.=debug
Adjusting the log level of the report generator class in your application.properties
Spring Boot 1.x
logging.level.org.springframework.boot.autoconfigure.logging.AutoConfigurationReportLoggingInitializer=debug
Spring Boot 2.x
logging.level.org.springframework.boot.autoconfigure.logging.ConditionEvaluationReportLoggingListener=debug
Starting your application with --debug will log an auto-configuration report that shows every auto-configuration class that was considered during startup and whether or not it was activated. Every class listed as a positive match has been activated and every class listed as a negative match has not been activated.
If your application's using Spring Boot's Actuator (it has a dependency on org.springframework.boot:spring-boot-starter-actuator), then, as mentioned in the question comments, you can also access the report over HTTP using the /autoconfig endpoint.
Related
is there any difference between debug=true and logging.level.root=debug , both are specified in application.properties file of spring boot application.
Below are references for both from spring boot documentation, unfortunately there they don't show any link between them but it looks like they serve same purpose.
https://docs.spring.io/spring-boot/docs/2.6.6/reference/htmlsingle/#features.logging.console-output
https://docs.spring.io/spring-boot/docs/2.6.6/reference/htmlsingle/#features.logging.log-levels
When you set debug=true a bunch of "core" loggers used under the hood by spring boot will be set to debug: web container (like a tomcat), spring boot itself, hibernate.
It won't affect the loggers of your application though - they'll still be at INFO severity level.
However, if you set something like logging.level.root=debug probably all the loggers will be set to DEBUG, so yes, technically there is a difference.
From the spring boot documentation:
When the debug mode is enabled, a selection of core loggers (embedded container, Hibernate, and Spring Boot) are configured to output more information. Enabling the debug mode does not configure your application to log all messages with DEBUG level.
As a developer, I use the default dev profile in my local development environment. Here is part of my application-dev.properties file:
# Profiles
spring.profiles.include=auth
Previously I used Spring Boot 2.3.0.RELEASE and the spring.profiles.include property included auth profile at runtime.
But after I migrated to Spring Boot 2.4.0, I don't get the auth profile enabled. spring.profiles.include property doesn't seem to work as before.
Please tell me how I can configure my profiles so that I get the same result as before migration. (I would not like to use profile groups here)
Thanks in advance!
In case your configuration processing has changed in incompatible ways and you wish to use the "legacy" processing way, you can re-enable it by setting:
spring.config.use-legacy-processing=true
or alternatively, using YAML:
spring:
config:
use-legacy-processing: true
which should revert the configuration processing to the 2.3.x equivalent. Do note, however, that this property exists solely to ease the migration of profile configurations from 2.3.x to 2.4.x and will likely be deprecated and removed in a future major release1, so you should still try to migrate ASAP. To understand the reason for this change and some additional information, read on.
Of note in 2.4.0 are the following two paradigms:
So in Spring Boot 2.4 we’re planning to make two significant changes to the way the properties and YAML files are loaded:
Documents will be loaded in the order that they’re defined.
Profiles can no longer be activated from profile specific documents.
This change has in fact made the what-overrides-what-when logic considerably simpler to digest, but leads to having to disable some functionality. For example:
my.prop: test
---
spring.profiles: prodprops
my.prop: prod
---
spring.profiles: prod
# no longer works - activating a profile from a profile-specific document!
spring.profiles.include: prodprops
would lead to an exception as the configuration attempts to activate a profile from a profile-specific document, which is not allowed anymore.
To cover this use case (and others), profile groups have been added as a feature. This means that to enable your previous behaviour, you would need to create a profile group as follows:
spring.profiles.group.<group>=dev, auth
or alternatively, in YAML:
spring:
profiles:
group:
<group>: dev, auth
Where <group> is the name of your chosen profile group. Note that you can define multiple groups, all of which should have different names. If you then start your application using the <group> profile, all the profiles that are part of that group should be activated.
As a side-note, Spring Boot 2.4.0 additionally added support for multi-document properties files, which look as follows:
test=value
spring.profiles.active=local
#---
spring.config.activate.on-profile=dev
test=overridden value
Note the document separator (#---). This allows you to have similar overriding logic in .properties files as in .yml files.
Again, this and other information is provided in the relevant update post.
1 If prior deprecations are any indicator, the property should be removed in 2.5.0 at the earliest or 2.6.0 at the latest, with the latter being more likely (and a deprecation as of 2.5.x).
You can use spring.config.import using classpath:
spring.config.import=classpath:application-DEV.yml,classpath:application-auth.yml
Although we have an accepted answer above. But I would share my solution via multiple files.
I'm having multiple config files in my project
./
application.yml
application-auth.yml
application-mockauth.yml
application-datasource.yml
The body of application-auth.yml or application-datasource.yml are the same as we're implementing before spring boot 2.4. Minor adjustment will be located inside application.yml
spring:
profiles:
group:
"dev": "datasource,mockauth"
"prod": "datasource,auth"
Instead of spring.profiles.include, you will group related config with environment name (dev, prod...).
You can also use spring.config.import to import configuration from other file according this documentation Config file processing in Spring Boot 2.4.
I have been prototyping with Spring boot where I added dependency on spring-boot-starter-actuator and spring-boot-starter-data-rest and named my testing REST endpoint to /info. Application ran without any errors however my endpoint couldn't be called and app returned 404 all the time.
After some time I found out that actuator project contains SAME endpoint /info and basically overrides my custom RESTful endpoint since I didn't name it.
My question is: Is there any way how I can prevent such behavior in general (meaning bean clashing by mistake)? Or at least get WARN message when this is happening.
Thanks in advance for your answers
You can disable /info actuator endpoint by using the following property;
management.endpoint.info.enabled=false
Actually all can be disabled, or you can enable only certain ones, if you check the source link I've provided below;
By default, all endpoints except for shutdown are enabled. If you prefer to specifically “opt-in” endpoint enablement you can use the endpoints.enabled property.
source
For logging of this behaviour, while deploying you can see the endpoints and corresponding beans, you can deduce from this log I guess. But better not to use same endpoint with actuator while they are enabled.
Yes, there is a chance to disable particular classes by #EnableAutoconfiguration with a parameter exclude= where you can specify classname or whole package by using {} brackets
Example:
#EnableAutoConfiguration(exclude = {MyClassName.class}
#EnableAutoConfiguration(exclude = {MyClassName.class, MyClassName2.class})
I have a spring-boot app that autoconfigures an instance of Netflix's DynamicPropertyFactory. This enables us to read any properties spring is aware of plus any additional sources we specify.
The issue arises when we change a spring property that is used in core spring classes. For example logging.level.org.springframework.web=INFO is used on core classes or spring before, during, and after applicationContext setup. If we change this property while the application is running to say logging.level.org.springframework.web=TRACE...
dynamicPropertyFactory.getInstance().getStringProperty() eventually realizes the change. However, the spring core classes continue to log at INFO rather than change to TRACE as expected.
I'm running a Spring Boot application.
When there's no application.properties file in standard config paths it is not loaded and default configuration seems to be loaded.
application.properties:
spring.datasource.url=jdbc:sqlserver:...
Because of that, Spring Boot creates empty database with scheme without data which leads to empty program output.
How can one prevent Spring Boot from loading database default configuration?
you can use something as follows exclude in #EnableAutoConfiguration annotations to exclude Datasource default configuration. Reference
#EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
I don't know if there is any provision to make the app fail fast.
In order to stop Spring-Boot from autoconfiguring certain features for you, you need to explicitly exclude the corresponding class from the auto-configuration config:
#EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
Note: using this annotation you are taking back the responsibility from Spring to setup things for you, so you need to configure your DB properly from now on.