I was searching for the difference between the #Configuration vs #SpringBootConfiguration. I found many articles mentioned "As per the Spring documentation, #SpringBootConfiguration is just an alternative to the Spring standard #Configuration annotation. The only difference between the two is that the #SpringBootConfiguration allows the configuration to be found automatically".
So what does it mean by #SpringBootConfiguration allows the configuration to be found automatically? If we use the #Configuration for a class that contains #Bean annotated methods, Spring will create instantiation for those beans as well. Can anybody explain this to me clearly?
Because this question was driving me a little crazy and this was the first StackOverflow page I found, which didn't resolve the issue for me, I'm going to try to explain my findings:
#SpringBootApplication is a specialisation of #SpringBootConfiguration, which is a specialisation of #Configuration.
You may only have 1 #SpringBootConfiguration, which means you can't have both a #SpringBootConfiguration and a #SpringBootApplication in your application.
"#SpringBootConfiguration allows the configuration to be found automatically" means you don't have to do anything to have this (and therefore #SpringBootApplication) found. Other #Configuration classes are generally discovered by #ComponentScan
An extra advantage over #Configuration, is that it will be discovered by #StringBootTest.
Just open https://github.dev/spring-projects/spring-boot/tree/main/spring-boot-project/spring-boot-docs/src/docs/asciidoc and search for SpringBootConfiguration you will find some information about it.
such as
#SpringBootConfiguration: enable registration of extra beans in the
context or the import of additional configuration classes. An
alternative to Spring’s standard #Configuration that aids
configuration detection in your integration tests.
and
Detecting Test Configuration If you are familiar with the Spring Test
Framework, you may be used to using #ContextConfiguration(classes=…)
in order to specify which Spring #Configuration to load.
Alternatively, you might have often used nested #Configuration classes
within your test.
When testing Spring Boot applications, this is often not required.
Spring Boot’s #*Test annotations search for your primary configuration
automatically whenever you do not explicitly define one.
The search algorithm works up from the package that contains the test
until it finds a class annotated with #SpringBootApplication or
#SpringBootConfiguration. As long as you structured your code in a
sensible way, your main configuration is usually found.
Related
I want to use Mongock migration tool to initialize my app's configuration that is stored in database.
The problem I have is that one of my configs is used in class that is annotated with #Configuration. As Mongock changesets are executed after #Configuration it cannot retrieve not existing yet value from database and that results in a crash of application. Is there a way to postpone creating #Configuration class? Or should I initialize this one config without using mongock?
I don't fully understand your issue. I think that you need Mongock to run before your class annotated with #Configuration is processed. As you mention, SpringMongock requires the configuration class to be processed, as it requires the Spring ApplicationContext. However, you can run Mongock as standalone runner and use it(run it) wherever you want, as it doesn't depend on Spring context.
Mongock documentation
I hope it helps.
I have started a spring boot project using start.spring.io.
But I am getting this error-
I have read various articles on the internet about this issue and they all say about putting my tests in the same package as my Main class.
But I already have the same.
Could you point out what is wrong with my configuration?
The exception is pretty clear: You are missing a configuration for your spring context. What you need to do is to add the configuration classes for your context like so:
#SpringBootTest(classes = { TestConfiguration.class })
whereas your TestConfiguration class must be annotated with
#Configuration
and/or
#EnableAutoConfiguration
There you can add configurations to your liking. You can of course also use your DatabaseApplication class as Configuration although Im wouldn't recommend that.
The search algorithm works up from the package that contains the test until it finds a #SpringBootApplication or #SpringBootConfiguration annotated class. As long as you’ve structure your code in a sensible way your main configuration is usually found.
Make Sure your DatabaseApplication class is annotated with #SpringBootApplication .
I seems have problem understanding these 2 annotation. I have try to read the javadocs but still cannot figure out. Can anyone help to explain with simple code about these 2 ?
Thank so much in advance.
You use #Configuration as a replacement to the XML based configuration for configuring spring beans. So instead of an xml file we write a class and annotate that with #Configuration and define the beans in it using #Bean annotation on the methods.
And finally you use AnnotationConfigApplicationContext to register this #Configuration class and thus spring manages the beans defined. Small example you can find at Spring Configuration Documentaion.
Quoting from the above link
It is just another way of configuration Indicates that a class declares
one or more #Bean methods and may be processed by the Spring container
to generate bean definitions and service requests for those beans at
runtime.
And #Configurable is an annotation that injects dependencies into objects that are not managed by Spring using aspectj libraries. i.e., you still use old way of instantiation with plain new operator to create objects but the spring will take care of injecting the dependencies into that object automatically for you.
#Configuration is the heart of the Java-based configuration mechanism and provides an alternative to XML-based configuration.
#Configuration classes are just like regular #Components classes, except that methods annotated with #Bean are used to factory beans.
I am attempting to migrate a spring, non-boot, app to a boot app. The current one builds a war file. Following these instructions, I am walking through the steps to migrate.
I am finding that the #SpringBootApplication annotation forces a lot of things to fail. For instance, it tries to auto config security when I really need the existing xml security config to remain as is. I found that I can override #EnableAutoConfiguration and exclude configuration classes (.i.e. SecurityAutoConfiguration.class). But I am finding it is doing this a great deal for the items I already have on my classpath. I decided it would be better to remove #SpringBootApplication and replace it with just #Configuration, #ComponentScan and #ImportResource to load my original context xml. The class extends SpringBootServletInitializer so that I can register my custom servlets and filters.
What I have found, it now no longer knows to load the application.yml or bootstrap.yml. What triggers auto configuration of these files? Do I fall back to loading with the traditional properties placeholder configurers? I want to avoid this as the next step is to hook it up to spring cloud config to centralize the management of the application configuration.
#SpringBootApplication is a alternative for #Configuration, #EnableAutoConfiguration and #ComponentScan.
Probably you want use #Configuration + #ComponentScan. If you want load xml configuration you can use: #ImportResource annotation.
If you want use autoconfiguration, but you can disable a few auto configurations, eg:
#EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
Details:
http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-auto-configuration.html
http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-configuration-classes.html
http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-using-springbootapplication-annotation.html
Why do we use #ComponentScan annotation in spring ? I am not being able to figure out the exact difference between context:componentscan in xml file and #ComponentScan annotations in java and how to use them in case of classes which have been annotated with #Configuration
In short, there is no difference.
#ComponentScan - Used with #Configuration classes, for example, when you have java-based configurations for Spring.
It provides support parallel with Spring XML's <context:component-scan> element. The purpose of those two are exactly the same - to scan spring components.
But there is one advantage of xml based configuration - you don't need to compile your java code. When you added some package under <context:component-scan> then you don't need to compile java source code. Place the xml configuration file in your server and restart it.