What happens internally when running a Spring Boot application?

Question

Recently I have been studying Spring Boot, I wanted to know what happens internally when an application is started, because every project has a main class that is always noted with @SpringBootApplication. What is the purpose of this note?

Answer 1

In general, Spring Boot cares about 3 main things on its startup:

1) Automatically configure your project from the dependencies you declare in the build system (pom.xml - Maven or build.Gradle - Gradle) on which your project is built. This is done by the annotation @EnableAutoConfiguration.

2) Scan your project for classes that have certain specific annotations (such as @Service or @Repository, for example), to inform that these classes must have their life cycle managed by Spring. These classes are the Beans and the fruit of this management is nothing more than the injection of dependence (the @Autowired that you have surely seen). The sweeping act is triggered by the annotation @ComponentScan.

3) Define the class containing the method itself main be herself a bean, noting it with @Configuration. Why? To allow you to, should you wish, have others Beans (previously scanned by item 2) injected into this class, saving you the need to create additional classes for this. Remembering that only one class bean (that is, managed by Spring) may have injected into it other Beans.

Well, for convenience, instead of you annotating your class with the 3 bold notes, just write it down with @SpringBootApplication, which will get the same effect, with the default settings of Spring Boot.

Extending a little your question: but, why there is the method main()? To allow your application to run as a common Java application, which, as we know, is started from a method main(). How a Spring Boot program has its own Servlet container (Tomcat by default) and everything you need to "deploy yourself and boot yourself" just one entry point (the method main()) for him to be executed.

It is different from an application made in Spring MVC, for example, where you need to indicate an external Tomcat (and that is already pre-installed), startar this container yourself to only then run your application. That’s not counting all the "in hand" configuration you’ll need to do to make your project functional.

And then you ask, but why doesn’t Spring MVC follow this same startup concept?

The first point is that Spring MVC is an implementation of the Java EE Servlet API (web system interface) with (many) advantages and facilities for development. And any Servlet API implementation needs an application server (Tomcat, Jboss, Glassfish etc.) to run, with all the configuration and boot "bureaucracy" involved.

The second point is that beneath the surface, Spring Boot has Spring MVC (after all, Boot remains a web system development framework), but with the "bureaucracy" conveniently automated as much as possible.

But, and here comes the big but, the Spring Boot was already thought taking into account the distributed microservices architecture, in other words, small self-executable systems (looks at the need of the method main() ) and scalable that must be independent of centralized application server to be executed, launched, "killed" when necessary, replaced and redeployed. This type of microservice, in fact, should behave like a desktop application, isolated and self-sufficient, with the least amount of external dependency possible. These features are not found in a Spring MVC project, but they are what made Spring Boot so popular and so widely used around the world.