Shulou(Shulou.com)06/01 Report--

This article mainly explains "Spring Boot Starters use case Analysis". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "Spring Boot Starters usage case Analysis".

The biggest advantage of Spring Boot over Spring MVC is that it is easy to use and the convention is greater than the configuration. Unlike before using Spring MVC, from time to time, I was confused by the xml configuration file, and unexpectedly, because of a bit of negligence in the configuration of xml, the whole project was inexplicably unavailable, and I suddenly felt that I had nothing to attach to in my life.

This is due to the various starters that make up Spring Boot, both officially provided and open source by third parties. It's fair to say that basically all the features you plan to use can be found, and if you don't find them, look again.

The steps to use the functional components of Spring Boot (such as spring-boot-starter-actuator, spring-boot-starter-data-redis, etc.) are very simple, and if summarized by the famous method of putting elephants in the refrigerator, you can complete the use of the component functions in the following three steps:

STEP 1

Introduce the corresponding package in the pom file, for example:

Org.springframework.boot

Spring-boot-starter-actuator

STEP 2

Add the appropriate configuration to the application configuration file. The configuration is agreed upon by the component. You need to check the official documentation or related instructions. Some of the more complex components, the corresponding parameters and rules also correspond to more, a little bit as big as dozens of hundreds.

STEP 3

When the above two steps are normal, we can use the relevant interfaces provided by the component to develop business functions.

Isn't that right? we don't know how many times we have practiced this process in our daily development. So why can Spring Boot be so easy to use? what kind of working mechanism is it? I don't know if you have studied it.

The following is a demo starter created to understand the implementation mechanism of Spring Boot components. What is the significance of understanding the principle to our future work?

1. When we encounter problems, it can help us to have a better idea of troubleshooting.

two。 It can help us read the source code correctly, where is the component entry, what are the configuration properties, and so on.

Above

Next, let's start implementing this simple starter, which has no actual functionality, just for demonstration purposes.

Before we begin, we need to understand what spring boot starter is.

In fact, starter will not contain much functional code, we can understand it as a "connection package" (I created the concept), according to this concept: it is first of all a package, a collection, it needs to use other functional components included, put in their own pom file. Then it is a connection, connecting the components it introduces to our project, and saving us the complex configuration in the middle, trying to make it the easiest to use.

There are four elements to implementing a starter:

Starter naming

Automatic configuration class, which is used to initialize the relevant bean

Indicates the configuration file spring.factories for the automatic configuration class

Custom attribute entity class that declares the application configuration properties of starter

All right, let's start implementing our demo.

1. Give starter a name.

This is the artifactId that we refer to in pom when we use it. There are rules for naming, official regulations:

The official starter is named in the format spring-boot-starter- {name}, such as spring-boot-starter-actuator mentioned above.

The unofficial starter is named {name}-spring-boot-starter. We named the custom starter as kite-spring-boot-starter and named it in the pom file.

Kite.springcloud

Kite-spring-boot-starter

Jar

1.0-SNAPSHOT

two。 Introduce automatic configuration packages and other related dependent packages

The implementation of starter mainly depends on automatic configuration annotations, so two jar packages related to automatic configuration should be introduced into pom.

Org.springframework.boot

Spring-boot-configuration-processor

Org.springframework.boot

Spring-boot-autoconfigure

In addition, other dependent packages should also be brought in.

3. Create a spring.factories file

Create a file named spring.factories in the resource/META-INF directory, why here? When Spring Boot starts, it looks for all files named spring.factories under classpath, and then runs the autoload class specified by the configuration in it to initialize the relevant bean in the specified class (one or more).

For example, the configuration information in this example is as follows:

Org.springframework.boot.autoconfigure.EnableAutoConfiguration=\

Kite.springcloud.boot.starter.example.KiteAutoConfigure

The equal sign is written in a fixed way in front of it, followed by our custom automatic configuration class, which is separated by English commas if there are multiple.

4. Write automatic configuration classes

The autoconfiguration class is used to initialize the relevant bean in starter. It can be said to realize the core function of starter.

@ Configuration

@ ConditionalOnClass (KiteService.class)

@ EnableConfigurationProperties (KiteProperties.class)

@ Slf4j

Public class KiteAutoConfigure {

@ Autowired

Private KiteProperties kiteProperties

@ Bean

@ ConditionalOnMissingBean (KiteService.class)

@ ConditionalOnProperty (prefix = "kite.example", value = "enabled", havingValue = "true")

KiteService kiteService () {

Return new KiteService (kiteProperties)

}

}

The code is very simple, looking at, the most is a variety of annotations.

@ Configuration does not need to be explained, indicating that this is an automatic configuration class, which we usually use when working on projects, usually when reading configuration files.

@ ConditionalOnClass (KiteService.class):

This autoconfiguration class is resolved only if the KiteService class is found in classpath, otherwise it is not resolved.

@ EnableConfigurationProperties (KiteProperties.class):

Enable the configuration class.

Bean: instantiate a bean.

@ ConditionalOnMissingBean (KiteService.class):

In conjunction with @ Bean, the annotated code block will be executed only if a bean does not exist in the current context, that is, if there is no bean instance of KiteService in the current context, the kiteService () method will be executed to instantiate an bean instance.

@ ConditionalOnProperty:

The annotated block of code is executed only when there is a relevant configuration in the application configuration file.

The overall meaning of this class is: when this configuration class is parsed when there is a KiteService class in classpath, it will only exist in classpath, that is, the project references the relevant jar package. And if there is no bean instance of KiteService in the context, an instance of new comes out and the relevant configuration values in the application configuration are passed in.

5. Implement the property configuration class

@ Data

@ ConfigurationProperties ("kite.example")

Public class KiteProperties {

Private String host

Private int port

}

The configuration class is simple, with only two properties, one host and one port. The configuration parameter is prefixed with kite.example. We'll see how to declare configuration properties when we use this starter later.

6. Implement related functional classes

That is, the KiteService mentioned above, strictly speaking, this business function class should not be placed in starter, but should be placed in a separate jar package, but here demo is very simple and is written here.

@ Slf4j

Public class KiteService {

Private String host

Private int port

Public KiteService (KiteProperties kiteProperties) {

This.host = kiteProperties.getHost ()

This.port = kiteProperties.getPort ()

}

Public void print () {

Log.info (this.host + ":" + this.port)

}

}

A constructor and a print method.

7. Packing

Install this starter to the local maven repository through the maven command

Mvn install

It can also be posted to your private server through mvn package deploy.

Or publish it to the central warehouse.

The above has completed the development of starter, installed it in the local repository, and then used it in our project.

1. Create a project, referencing in pom

Kite.springcloud

Kite-spring-boot-starter

1.0-SNAPSHOT

two。 Apply configuration item

Create an application.yml with the following configuration:

Server:

Port: 3801

Kite:

Example:

Enabled: true # takes effect when enabled

Host: 127.0.0.1

Port: 3801

3. Invoke the service method of KiteService

@ RestController

@ RequestMapping (value = "use")

Public class UseController {

@ Autowired

Private KiteService kiteService

@ GetMapping (value = "print")

Public void print () {

KiteService.print ()

}

}

4. Start the service and access the interface

Visit the / use/print interface and you will find that the configuration information is printed in the log.

2019-05-24 16 INFO 4515 04.234 INFO 36687-[nio-3801-exec-1] k.s.boot.starter.example.KiteService: 127.0.0.1 k.s.boot.starter.example.KiteService 3801

Following the ideas above, let's take a look at the structure of the official starters. First, let's clone Spring Boot from github. When you open it with idea, you can see that the project structure is as follows

Spring-boot-starters is the main official starters, such as jdbc, redis, security, web and so on.

Let's take the starter of spring-boot-starter-data-redis as an example to talk about how the government organizes the project structure and the order in which the source code should be read.

1. Expanding redis starter under Spring-boot-staters, we see the directory structure as follows

There is no Java code, only a spring.provides file, which contains the following contents:

Provides: spring-data-redis,lettuce-core

This means that the project relies on the spring-data-redis and lettuce-core packages and is referenced in the pom file. The goal is to tell the user that when referencing this package, there is no need to reference the dependent package in provides.

two。 Then there is automatic annotation. All stater automatic annotation classes and attribute configuration classes are placed under the project spring-boot-autoconfigure.

Have you seen the familiar spring.factories? we have implemented it ourselves before. This is a lot of content, we only look at redis-related

Org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,\

Org.springframework.boot.autoconfigure.data.redis.RedisReactiveAutoConfiguration,\

Org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration

Contains three automatic configuration files, and then along the configuration, we find the package

Then you can start reading the code. Other starter have the same structure.

At this point, I believe you have a deeper understanding of the "Spring Boot Starters use case analysis", you might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.