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

This article introduces the "custom Spring Boot Starter development tutorial" related knowledge, in the actual case operation process, many people will encounter such a dilemma, and then let the editor lead you to learn how to deal with these situations! I hope you can read it carefully and be able to achieve something!

1. Preface

With the increasingly bloated Spring, in order to simplify configuration, out of the box, and rapid integration, Spring Boot came out of nowhere. At present, it has become the hottest framework of Java. Usually we use Spring Boot to develop web applications. Spring mvc uses the tomcat servlet container by default because the Spring mvc component integrates with spring-boot-starter-tomcat. But now the performance of the undertow servlet container is very good. We can first exclude tomcat in the following ways:

Then replace it directly with undertow:

The code does not need to be changed. This is the benefit of componentization: 1. Pluggable. two。 Customizable. 3. Integration on demand. Why can you adapt quickly? Let's imagine such a scenario: if a screw on the wheel of your car is broken, you have to buy a screw to install it yourself. When you go to the store, as long as you report the brand and location of your car, the boss will know exactly what kind of screw you want to use. This is the benefit of the standards that have been established. If there is no standard, you can easily buy mismatched screws, and you have to keep trying and making mistakes. This is obviously not what you want. If we imperceptibly influence this standard, then we will communicate more quickly and conveniently. Sometimes your girlfriend gives you a look and you know what she wants. So Spring Boot has a rule that "convention is greater than configuration", which allows program components to reduce configuration and complexity. Therefore, when you develop a custom Spring Boot Starter, it is best to consider how your starter can achieve the above convenience.

2. Some agreements of Spring Boot

The design of a component must have standards and rules. Spring Boot Starter is no exception. Let's take a look at some conventional practices.

2.1 naming style

If you are going to have a baby, you must have a name before you are born. The name marks the pedigree of you and your lover, and it will certainly not have the surname of Lao Wang next door, and it will certainly attract strange eyes. In maven, groupId represents the last name and artifactId represents the first name. Spring Boot also has a naming suggestion. GroupId do not use the official org.springframework.boot, but use your own unique. For artifactId naming, Spring Boot officially recommends that unofficial Starter naming formats follow xxxx-spring-boot-starter, such as mybatis-spring-boot-starter. The official starter will follow spring-boot-starter-xxxx, such as the spring-boot-starter-undertow mentioned above. Many open source starter authors ignore this convention and appear unprofessional.

3. Customize a Starter

Next, we build a custom third-party SMS starter, named sms-spring-boot-starter. There are some details to be introduced while writing. Here is a template that omits samples and test modules:

Based on the above, we set up the following projects:

3.1 sms-spring-boot

The important thing about sms-spring-boot building a project is dependency management. So it is necessary to introduce BOM. All the modules that mainly manage the starter, module, and all dependencies of starter, and even sms-spring-boot-autoconfigure, are managed by sms-spring-boot.

3.2 sms-spring-boot-autoconfigure

This module is mainly used to define configuration parameters and automatically configure the function of exposure (usually an abstract interface Spring Bean).

3.2.1 configuration parameters

The general configuration parameters are in the application.yml of Spring Boot. We will define a prefix identity as a parameter for namespace isolation of individual components. The corresponding component defines a XXXXProperties to automatically assemble these parameters. The auto-assembly mechanism is based on the @ ConfigurationProperties annotation, so be sure to explicitly declare your configured prefix identification (prefix). Our sms-spring-boot will be configured as follows:

The above configuration takes Ariyun's SMS feature as an example. When you use it in the future, you only need to add the configuration corresponding to SmsProperties above in application.yml:

You can also validate SmsProperties if you integrate the Spring Boot check library. Careful java developers will find that parameter configurations have the same description as the following when configuring application.yml:

Just like comments in java, it is as easy to understand the role of this configuration, which is actually generated by java comments. You need to rely on

The dependency then extracts the comments of the SmsProperties member attributes to generate a spring-configuration-metadata.json file, which is the metadata file for the configuration description. Spring Boot officials have also imposed some rule constraints on comments:

Do not start the description with "The" or "A".

For boolean types, start the description with "Whether" or "Enable".

For collection-based types, use "Comma-separated list"

If the default time unit is not equal to milliseconds, the default unit is described using java.time.Duration instead of long, for example, "seconds will be used if no duration suffix is specified."

Do not provide default values in the description unless it must be determined at run time.

I personally suggest that the description should be described in English as much as possible.

3.2.2 configure automatic exposure function interface

After getting the configuration, the next step is to initialize our functional interface according to the configuration. We will abstract an SMS sending interface SmsSender and design the function according to the SDK of the SMS provider. Note that the dependencies of autoconfigure modules are almost always non-transitive. That is, depending on the coordinates to configure optional to true. After the implementation of the functional interface, we will write an automatic configuration class SmsAutoConfiguration. In addition to the @ Configuration annotation, @ ConfigurationProperties will help us load our configuration class SmsProperties. Then declare the functional interface we need to expose as Spring Bean to expose to the Spring Boot application. Sometimes we can also control SmsAutoConfiguration or SmsSender by some conditions, such as whether or not to load or load different SmsSender according to certain conditions. When you look at redis-starter, you can clearly feel that it instantiates different client links according to the changes in luttuce, redisson, and jedis. You can do this by using the @ Conditional series of annotations, and you can learn about them sometime. Okay, our SmsAutoConfiguration statement is as follows:

3.2.3 active and passive effect

There are two ways to integrate starter into an application. From an application perspective, there are two types:

One is to take the initiative to take effect, which requires you to actively declare that the starter is enabled when the starter component is integrated into the Spring Boot application, even if you are fully configured. The @ Import annotation will be used here to mark it on your custom @ Enable annotation:

We can use the SMS function by tagging this comment into the Spring Boot app.

The other is passive, which is captured by the application when the starter component is integrated into the Spring Boot application. The SPI mechanism similar to java is used here. Create a new META-INF/spring.factories to write the SmsAutoConfiguration fully qualified name under the autoconfigure resource pack.

Multiple configuration classes are separated by commas and a backslash is used for line breaks.

3.3 sms-spring-boot-starter

The module is an empty jar. Its sole purpose is to provide the necessary dependencies to use starter. You can think of it as the only entrance to integrate the starter function. Do not make assumptions about the project to which the initiator was added. If the dependent libraries that you configure automatically usually require additional initiators, mention them as well. If the number of optional dependencies is high, it may be difficult to provide an appropriate set of default dependencies because you should avoid including dependencies that are unnecessary for the use of the typical library. In other words, you should not include optional dependencies. Either way, your starter must reference the core Spring Boot initiator (spring-boot-starter) directly or indirectly (if your initiator depends on another initiator, you do not need to add it). If only a custom initiator is used to create a project, the core functionality of Spring Boot is achieved through the presence of the core initiator. Our sms-spring-boot-starter is just the following pom:

At this point, our entire SMS Starter has been developed.

4. Summary

Custom starter is of great help to the modularization and modularization of our project. It is also a major feature of Spring Boot. I believe you are ready to try through Xiao Pang's introduction, so start writing one as soon as possible. If you think it's useful to you, you can like it and follow it.

This is the end of the "Custom Spring Boot Starter Development tutorial". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.