I am currently using spring boot with some 3rd parties starter.
I want to disable those AutoConfiguration and the EnvironmentPostProcessor in the starter during testing
I can disable AutoConfiguration by using #EnableAutoConfiguration(exclude ={xxx},
but cannot find any method to disable the EnvironmentPostProcessor. This blocks me from doing any test. Anyone can help?
Related
And most important, what's the reason behind the "Auto" prefix? Classes annotated with #Configuration rather than #AutoConfiguration are less automatic or something?
#Configuration is a spring framework annotation and not strictly bound to spring-boot. It was introduced when spring started to allow programmatic creation of spring-beans as to move forward from xml definitions of beans.
#AutoConfiguration is a spring-boot specific annotation not commonly available in spring framework. The reason it exists, is for external providers that cooperate with spring-boot to be able to mark some classes in some libraries they provide with this annotation as to inform spring-boot that those classes could be parsed and make some initializations during start up of spring application automatically.
So if some regular programmer that develops some application happens to have kafka in dependencies then some beans will automatically be created and added in application context and will be ready for the programmer to use, although he has not defined any configuration for them. Spring-boot already knows this as the kafka provider has already informed by marking some class in the jar they provide with the annotation #AutoConfiguration.
For this reason #AutoConfiguration has some more powerful configurations available as before, after, beforeName, afterName as to allow the provider to specify when the configuration is applied during application startup if some order is necessary.
So this annotation is not to be used from some regular programmer that develops an application using spring-boot. It is for someone that develops a library that other users might use with spring-boot. One such example is kafka library.
For this to work in a spring-boot project #EnableAutoConfiguration is needed as well, to enable auto configuration.
From spring documentation
Spring Boot auto-configuration attempts to automatically configure
your Spring application based on the jar dependencies that you have
added. For example, if HSQLDB is on your classpath, and you have not
manually configured any database connection beans, then Spring Boot
auto-configures an in-memory database.
#Configuration instead is to be used from some regular programmer that develops an application using spring-boot or spring-framework as to inform the framework for which beans should be created and how.
#AutoConfiguration was introduced in 2.7 with the idea to mark all auto-configurations with its dedicated annotation and move away from spring.factories for auto-configuration imports in 3.0 as described in Github issue.
According to Spring documentation:
[#AutoConfiguration] indicates that a class provides configuration that can be
automatically applied by Spring Boot. Auto-configuration classes are
regular #Configuration with the exception that
Configuration#proxyBeanMethods() proxyBeanMethods is always false.
Usually, #AutoConfiguration classes automatically configure an application based on the dependencies that are present on the classpath. Those classes are generally marked as #ConditionalOnClass and #ConditionalOnMissingBean annotations that detect the presence or absence of specific classes.
Additionally, if a configuration needs to be applied in a specific order, you can use the before, beforeName, after, and afterName attributes on the #AutoConfiguration, unlike #Configuration which doesn't provide those attributes.
Im trying to connect to Pivotal Cloud Cache server Regions.
I'm using #EnableClusterAware and trying to configure the client Regions via ClientRegionFactoryBean as below:
#Bean("clientRegion")
ClientRegionFactoryBean someClientRegion(GemFireCache gemfire) {
// ...
}
Either GemFireCache or ClientCache beans are not available with the annotation #EnableClusterAware. It's available only with #ClientCacheApplication.
Is there any annotations that needs to be used in conjunction with #EnableClusterAware so that GemFireCache gets injected?
Please help.
When Spring Boot for Apache Geode, or alternatively GemFire, (SBDG) is on the classpath of your Spring Boot application (see here), then SBDG auto-configuration will automatically create and configure a ClientCache instance for you (see here).
TIP: You can also review the Getting Stated Sample Guide and Source to see this behavior in action, for yourself. The Guide also talks about the use of the #EnableClusterAware annotation, here.
The #EnableClusterAware annotation is simply a development-time, SBDG annotation that enables you to switch between environments (e.g. local vs. managed, such as when pushing your Spring Boot application up to run in PCF, connected to PCC, and then testing locally in your IDE) without having to change any configuration (hence the goals).
The #EnableClusterAware annotation does not create any GemFire/Geode cache instances for you. Only SBDG's auto-configuration, or declaring an explicit SDG annotation (e.g. #ClientCacheApplication) will do that for you. Still, when using SBDG auto-configuration, you do not need an explicit SDG cache application annotation, like #ClientCacheApplication, since SBDG auto-configuration (again) creates and configures a ClientCache instance by default.
TIP: See the documentation on the #EnableClusterAware annotation for more details.
If ClientCache is not provided (auto-configured), then you are not:
Using SBDG, or rather do not have SBDG on the Spring Boot application classpath (see here)
Have not bootstrapped or configured and ran your Spring application with Spring Boot
Your Spring Boot application configuration is incorrect
You have explicitly disabled or overrode the SBDG auto-configuration
Etc.
One or more of these have to be true.
Is it possible to have spring integration xml configuration and spring boot java annotation configuration at the same time? Can you please refer with an example on this?
What is the best practice for this?
Thanks
As Marten pointed out it is fully fine to combine Spring Boot with an XML configuration. See Spring Boot docs: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using.configuration-classes.importing-xml-configuration
If you absolutely must use XML based configuration, we recommend that you still start with a #Configuration class. You can then use an #ImportResource annotation to load XML configuration files.
And here is the sample: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-tests/spring-boot-smoke-tests/spring-boot-smoke-test-xml/src/test/java/smoketest/xml/SampleSpringXmlPlaceholderBeanDefinitionTests.java
I work on a corporate Spring Boot extension that autoconfigures its own RabbitMQ clients. This extension (a starter) replaces the Spring Boot RabbitAutoConfiguration.
I know there are many ways to disable the RabbitAutoConfiguration :
in each Application (main) class with #EnableAutoConfiguration(exclude = RabbitAutoConfiguration.class) or #SpringBootApplication(exclude = RabbitAutoConfiguration.class)
in the application.properties or yml file (externalized or within the jar), with spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration
I wonder if there is a way that the presence of my new starter disables the Spring Boot RabbitAutoConfiguration.
I tried some dirty things, such as putting an application.properties with the exclude property in the corporate starter module, but as Spring Boot only reads one in the classpath, it can be easily overriden by one used in a client application. I do not want to impose some restrictions.
I do not like the idea of each application adding the same exclusion one way or the other (properties or annotation).
Any ideas ?
EDIT
I need to configure several RabbitMQ ConnectionFactory and RestTemplate within the same application.
If you want to truly replace the standard RabbitAutoConfiguration by yours, you just need to add #AutoconfigureBefore(RabbitAutoConfiguration.class) on your own auto-configuration to teach Spring Boot to process yours before the standard one.
If it is a replacement, yours will register beans that the standard auto-configuration will detect and it will back-off the same way as if you would have defined them manually.
Having said that, why are you doing this? I'd rather complement the existing auto-configuration rather than replacing the standard one. Is there a problem with the standard one? If so, we'd love to hear about it and adapt the code so that you don't have to fully replace it.
I have a basic question about Spring Boot:
Say I am developping a websocket app. It seems the idea behind Spring Boot is as follows:
As a developer I am responsible for:
Including the following mvn dependency: spring-boot-starter-websocket
Annotate my configuration class with: #EnableAutoConfiguration
Spring Boot is then responsible for applying the following config: WebSocketAutoConfiguration
In a nutshell, is it how it works? Can someone please confirm of infirm the above?
You are absolutely correct.
After adding spring-boot-starter-websocket to your configuration file and using the #EnableAutoConfiguration annotation, Spring will use you class path to automatically determine which configuration settings and beans need to be created for you.
Spring Boot will handle the WebSocketAutoConfiguration and any other necessary common configurations.
More information can be found here: https://spring.io/guides/gs/spring-boot/