[SpringBoot series] SpringBoot packaging and operation

Pre-import

The little friends who have just started to develop and learn may have a wrong understanding of knowledge. We write programs every day under Idea, and they also run under Idea.

But after the actual development is completed, it is impossible for our project to run on our own computer.

The programs we will make in the future will run on a dedicated server. Simply put, you will put the programs you make on a computer that runs independently. This computer is more professional than the computer you developed and used, and it has various security levels. Much more than your current computer.

How to place our program on this dedicated computer, which requires organizing our program into a file, and then transferring this file to this server. There are two processes here, one is the packaging process, and the other is the running process.

In order to ensure the adaptability of the environment, the enterprise project will use the following process to release the project:
① The development department uses Git, SVN and other version control tools to upload the project to the version server
② The server uses the version control tool to download the project
③ The server uses the Maven tool on the current real machine Rebuild the project in the environment
④ Start the service

in conclusion:

• Packaging refers to converting a program into an executable file
• Run refers to 不依赖开发环境executing the files generated by packaging

The above two operations have corresponding commands that can be quickly executed.

Program packaging

The SpringBoot program is created based on Maven, and Maven provides packaged instructions, called package. This operation can be performed in the Idea environment.

//在终端项目路径输入
mvn package

After packaging, a jar file similar to the project name will be generated, and its name is composed of module name + version number + .jar:

The jar package is in the target folder where your project is located

Of course you can also directly:

Or in Maven on the right side of the IDE, you can also click package:

Notice:
We can notice that there is also a test before the package life cycle. According to the characteristics of Maven, when we execute the package command, the previous life cycle will be executed. That is to say, we will also perform a test before packaging, if we build something in the test that affects the data source. Then when we package the project again, we will find that the data has changed when we execute it.
At this time, we have to skip the test cycle (if your test has no effect on the data layer, you can skip it), there are many methods, here is only one: click

the blue lightning icon and find that the test item is grayed out If there is a line, it means it takes effect:

Program running

After the package is ready, it can be executed directly. In the path where the package is located, execute the command.

java -jar 工程包名.jar

​ After executing the program packaging instruction, the program runs normally, which is no different from executing the program under Idea.

​Special attention : If you do not have the java jdk environment installed on your computer, the above operations cannot be performed correctly, because the program execution uses java instructions.

​Special attention : When using the wizard to create a SpringBoot project, there will be the following configuration in the pom.xml file. This configuration must not be deleted, otherwise the program cannot be executed normally after packaging.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Summarize

1. The SpringBoot project can start the service based on the independent running of the jar file in the java environment
2. The SpringBoot project executes the mvn command package for packaging
3. Execute the jar command: java –jar project name.jar

SpringBoot program packaging failure handling

After some small partners are packaged and executed, there will be some problems, causing the program to not execute normally, such as the following phenomenon

If you want to figure out this problem, you need to talk about the working mechanism of the .jar file. If you know this thing, you will know how to avoid such problems.

​ In java development, you will usually come into contact with many jar packages, such as the mysql driver jar package, and what we get after packaging the program above is also a jar file. At this time, if you use the above java -jar command to execute the mysql driver jar package, the above-mentioned unexecutable phenomenon will occur, and why can our SpringBoot project be executed? In fact, it is because of the different packaging methods.

​ There is the following set of configurations in the pom.xml of the SpringBoot project. This set of configurations determines whether the packaged package can be executed.

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

​ We open this configuration and comment out this configuration to perform two packages respectively, and then observe the difference between the two packaged packages. There are 3 obvious features.

• The size of the files after packing is different
• The contents of the package are different
• The contents of individual files in the packager are different

​ First look at the first phenomenon, the file size is different. The package size generated by packaging with configuration is as follows:

​ It is not difficult to see that the package volume with configuration is 30 times larger than that without configuration, so what is in it? Can it be that much? Let's see what's the difference inside.

​ We found that the content is completely different, only one directory is the same, called META-INF. Open the classes directory under the BOOT-INF directory in the large-capacity package, and we find that the content is exactly the same as that in the small-capacity package.

​

​ It turns out that in addition to the contents of the small package, there are other things in the large package. What are there? Go back to the BOOT-INF directory, open the lib directory, and there are many jar files displayed.

​ It is not difficult to find that these jar files are the files corresponding to the coordinates imported when we made this project. You can probably figure it out. In order to make the packaged and generated programs run independently, the SpringBoot program not only packaged the content developed by itself in the project, but also packaged all the jar packages that the current project needs to use. Why do it? Just to be able to run independently. The current program can run independently of any resources outside the package. This is also the main reason why large packages are 30 times larger than small packages.

​ Let’s take a look at the difference between the large package. The outermost directory contains an org directory. Enter this directory. The directory name is org\springframework\boot\loader, and you can find a JarLauncher.class file in it. Remember this file first. Looking at this set of directory names, it is obviously a Spring directory name. Why pack the Spring framework into this package? Not sure.

​ Go back to the outermost directory of the two packages, check that there is a file called MANIFEST.MF under the folder META-INF with the same name, but the size is different, open the file, and compare the contents.

• MANIFEST.MF for small files

  Manifest-Version: 1.0
  Implementation-Title: springboot_08_ssmp
  Implementation-Version: 0.0.1-SNAPSHOT
  Build-Jdk-Spec: 1.8
  Created-By: Maven Jar Plugin 3.2.0
  

• MANIFEST.MF for bulk files

  Manifest-Version: 1.0
  Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx
  Implementation-Title: springboot_08_ssmp
  Implementation-Version: 0.0.1-SNAPSHOT
  Spring-Boot-Layers-Index: BOOT-INF/layers.idx
  Start-Class: com.itheima.SSMPApplication
  Spring-Boot-Classes: BOOT-INF/classes/
  Spring-Boot-Lib: BOOT-INF/lib/
  Build-Jdk-Spec: 1.8
  Spring-Boot-Version: 2.5.4
  Created-By: Maven Jar Plugin 3.2.0
  Main-Class: org.springframework.boot.loader.JarLauncher
  

​ The large file obviously has a few more lines of information than the small file, and the last line of information is Main-Class: org.springframework.boot.loader. JarLauncher . What does this sentence mean? If you execute this package with java -jar, the class configured by the Main-Class property will be executed, which happens to be the file you saw earlier. It turns out that what appears in the Spring framework in the SpringBoot packager is for this service. And this org.springframework.boot.loader. JarLauncher class needs to find the class configured in the Start-Class property and execute the corresponding class. This property also exists in the current configuration, and corresponds to our bootstrap class name.

Now the role of this set of settings is clear

1. After adding the configuration to the SpringBoot program, a special package will be printed, including some functions of the Spring framework, the original project content, and the jar package that the original project depends on.
2. First read the Main-Class property in the MANIFEST.MF file to mark the class that runs after the java -jar command is executed
3. When the JarLauncher class is executed, it will find the Start-Class property, which is the name of the startup class
4. When running the startup class, the content of the current project will be run
5. When running the current project, it will use the dependent jar package and find it from the lib directory

​ It seems that SpringBoot has made a lot of effort in order to run the package independently, adding all the resources that need to be used to this package. That's why this jar package can run independently.

​ Look at the previous error message again:

​ Since that configuration was not used during packaging, an ordinary jar package was formed after packaging, and there is no attribute corresponding to Main-Class in the MANIFEST.MF file, so the runtime prompts that the main list attribute cannot be found. This is the reason for the error.

Summarize

1. The spring-boot-maven-plugin plugin is used to package the current program into a package that can run independently

Command line startup FAQs and solutions

When starting the SpringBoot project in the DOS environment, you may encounter the problem of port occupancy. The following commands may help you:

# 查询端口
netstat -ano
# 查询指定端口
netstat -ano |findstr "端口号"
# 根据进程PID查询进程名称
tasklist |findstr "进程PID号"
# 根据PID杀死任务
taskkill /F /PID "进程PID号"
# 根据进程名称杀死任务
taskkill -f -t -im "进程名称"