In the previous HelloWorld example, you got a taste of how springBoot automatically imports dependencies and completes configuration.
So how does SpringBoot work?
Dependency management features
Take a look at pom.xml from the previous content example:
<! GroupId >org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.3.4.RELEASE</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies>Copy the code
A parent project was added, and only one dependency was imported, spring-boot-starter-Web, and finally all of our related packages came in.
During the whole process, you don’t have to worry about the packet guide.
1. The parent project
Every Springboot project has a parent project, which is usually used for dependency management.
There may be many dependencies declared in the parent project, so if the child project inherits the parent project, it does not need to add the version number when adding dependencies later.
In the example above, the parent project uses the springboot version 2.3.4.RELEASE, so there is no need to write the version number for the dependencies added below.
(1) How does the parent project manage the version
You can enter by holding Down CTRL and clicking on the parent project.
Spring-boot-dependencies also has a parent project.
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> < version > 2.3.4. RELEASE < / version > < / parent >Copy the code
Go to spring-boot-Dependencies and see the properties TAB below:
This is a declaration of almost all the versions of jar packages we may use in our development.
Further down you can see the dependencyManagement, which is the version declared in properties.
Here’s an example:
On the left I see a package that is logback, so I search inside and find that the version defined here is 1.2.3.
So, the parent project’s main function is dependency management, almost declaring the version numbers of dependencies that are commonly used in development.
(2) Use the specified version
It is possible to use the specified version instead of the auto-mediated version.
For example, the mysql version, the auto-arbitration result is 8.0.21, but I only want to use the 5.1.43 version.
Add a Properties tag to declare the version.
. < the properties > < mysql version > 5.1.43 < / mysql version > < / properties >Copy the code
If you look at the imported dependency, it has already become the specified version.
2. Scenario initiator
Let’s look at one of the first imported dependencies: Spring-boot-starter-web:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
Copy the code
In the future, you will see more initiators named spring-boot-starter. There are also detailed instructions in the official documentation
What is a starter?
The starter is a set of dependent set descriptions, that is, usually we only need to introduce one starter, and then the entire development scenario will be introduced.
For example, if you want to start using Spring and JPA for database access, introduce a spring-boot-starter-data-jPA dependency into your project.
In addition, note that spring-boot-starter-* indicates the official naming method of the initiator.
So there are unofficial ones? Yes, you can customize your own starter if you feel that the official starter scenario doesn’t meet your needs.
However, it is recommended to use thirdPartyproject-spring-boot-starter as the custom naming method.
As for why you can import an entire scenario with just one starter, maven has the same dependency features as the parent project.
Go to spring-boot-starter-Web and scroll down to see the dependencies used to develop web scenarios.
Therefore, if you need to develop any scenario in the future, you only need to import the corresponding initiator according to the official documents.
Two, automatic configuration
Here’s a reminder of what SpringBoot automatically configured in the previous HelloWorld project:
- Automatically configure Tomcat
- Automatically configure springMVC
- Automatic provisioning of common Web features, such as character encoding issues
- Default package structure: the main package and all components in the following subpackages are scanned by default
- Various configurations have default values
- Load all automatic configuration items on demand
- .
1. Automatically configure components
Whatever is automatically configured, the steps are: import first, configure later.
For example, Tomcat requires the introduction of Tomcat dependencies, which is accomplished by dependency management described in part 1 above. After the introduction of web Starter, scenarios are automatically introduced.
The scenario is automatically introduced, which in turn introduces the various JAR packages used in the scenario, and then configures these things, such as Tomcat, springMVC, and so on.
Take springMVC for example. Before we used springMVC, we had to configure DispatcherServlet to intercept all requests for us.
<servlet>
<servlet-name>springMVC</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springMVC.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Copy the code
Now let’s take a look at where SpringBoot did the configuration for us in the helloWorld application.
Let’s start with the main program class:
// Mark this as a SpringBoot application, this class is the main program class, @springBootApplication public class MainApplication {public static void main(String[] args) { SpringApplication.run(MainApplication.class, args); }}Copy the code
You can create a local variable (Alt + enter), you can see this is a ConfigurableApplicationContext type.
@SpringBootApplication public class MainApplication { public static void main(String[] args) { ConfigurableApplicationContext run = SpringApplication.run(MainApplication.class, args); }}Copy the code
You can use the getBeanDefinitionNames() method to see what containers are contained and iterate over the print.
Public static void main(String[] args) {// Return IOC container final ConfigurableApplicationContext run = SpringApplication.run(MainApplication.class, args); / / check container components final String [] beanDefinitionNames = run. GetBeanDefinitionNames (); for (String name: beanDefinitionNames) { System.out.println(name); }}}Copy the code
Next, start the application and look at the console output.
CTRL +F search DispatcherServlet in console output:
The corresponding component is found in the IOC container.
2. Default package structure
The main program package and all components in the following sub-packages will be scanned by default, so we do not need to configure enable component scanning, can also be used normally.
But be aware of the scope:
In this example, the com.pingguo.boot package and all subpackages can be scanned automatically.
What if you want to put it outside, and you want it scanned?
You can extend the scope of the package by using scanBasePackages, an attribute in the @SpringBootApplication annotation of the main program class:
@SpringBootApplication(scanBasePackages = "com.pingguo") public class MainApplication { public static void main(String[] args) { ... .Copy the code
3. All configurations have default values
For example, the Tomcat port, when entering idea in the application.properties configuration file, can be seen with the default value 8080:
Click in to see the following are bound to the corresponding Java class.
The values of the configuration file are eventually bound to the corresponding class, which creates objects in the container.
4. Load all automatic configuration items as required
For example, if spring-boot-starter-web is used in the application, only the automatic configuration in the Web scenario will be enabled.
All automatic configurations in SpringBoot are here:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-autoconfigure</artifactId> < version > 2.3.4. RELEASE < / version > < scope > compile < / scope > < / dependency >Copy the code
Spring-boot-starter: spring-boot-starter: spring-boot-starter: spring-boot-autoconfigure: Spring-boot-autoconfigure
Third, summary
After the above steps, we can basically develop applications to achieve 0 configuration, both convenient and fast.
Springboot uses all sorts of clever encapsulation to get everything ready for the scenario you might want to use, and you just need to say it directly.
Help us get out of configuration hell and focus on the business.