background

In early September, summer fades and autumn cools. Lately, I’ve been getting up at 5am before dawn. It was dark before seven in the evening; The wheel of the four seasons, in people unaware of the rumble and over!

Mvn-x clean Install = mvN-x Clean Install = mvN-x Clean install = mvN-x clean install = mvn-x

Functional description

Recently involved in a product, technology combination is Maven multi-module + SpringBoot backend + vue.js front-end.

Yesterday, I was arranged by the leader to deploy the whole product. Although mVN-x clean install was executed under the root directory of the parent module, I also encountered three problems that only my former packaging colleague (who has become a former colleague) knew. To sum up,

If not, it is easy to package. Upload moduleName. War from the target directory of each module to the Tomcat webapps directory of the server and restart Tomcat. The project’s build.xml script packages all target wars into a webapps.zip file, unzip the file, and upload it.

Although I have deployed countless Web applications, I have backed up the Webapps directory on the server in advance to avoid accidents. As it turns out, caution is the ultimate tool, and the programmer’s sense of caution played a decisive role in later positioning problems.

Problem 1: blank pages

After deployment, when accessing the project menu module, a blank SpringBoot page appears: Troubleshoot problems: Restores the war package of the project to the backup version. The access is normal. It indicates that the direct cause is that the new package generated by MVN is faulty. Static resource files are not found in the project classes directory.

In theory, all front-end code should be packaged in the static directory of the corresponding SpringBoot backend project via NPM build. This blank page is likely to fail to access the front-end page file.

Why is this project not packaged with front-end files? Go to its POM.xml and see:

<id>exec-npm-install</id>
<phase>prepare-package</phase>
Copy the code

This preprocessing action was not configured, resulting in missing front-end files. All other modules with separated front and back ends have it. Why?

When I asked again and again, my former colleagues were impatient. The truth is that this module does not need to be repackaged and replaced, so there is no front-end packaging command configured.

Problem 2: The AXIOS request path is incorrect

After solving the first problem, the menu functions normally, but F12 sees a bunch of localhost:8080 request message 404 on the console. This problem has been known for a long time, because there is no complete independence between the project modules, so the configuration file is used to set the back-end request path of other modules:

const moduleUrl= {
    md1: 'http://localhost:8080/m1',
    md2: 'http://localhost:8080/m2',
};

export default moduleUrl;
Copy the code

The built-in Tomcat port varies according to the development environment, so you need to pay attention to port information when configuring the moduleUrl. However, localhost cannot be used in the path, because this is the front-end configuration. When browsing and accessing localhost, it is regarded as the local IP address, so the request fails.

Solution: In global path configuration, distinguish development environment and test environment, development environment, directly use relative path:

const moduleUrl= {
    md1: 'http://localhost:8080/m1',
    md2: 'http://localhost:8080/m2',
};

if (process.env.NODE_ENV === 'production') {
  moduleUrl.md1 = 'm1';
  moduleUrl.md2 = 'm2';
}
export default moduleUrl;
Copy the code

Problem 3: The context-path configuration is inconsistent with the release path

The last problem is that SpringBoot’s servlet:context-path configuration is inconsistent with the publishing path causing a front-end AXIOS request 404 error.

There is one module, which stands out from the rest, whose module root path is configured as / :

# Tomcat
server:
  tomcat:
    uri-encoding: UTF-8
    max-threads: 1000
    min-spare-threads: 30
  port: 8084
  servlet:
    context-path: /
Copy the code

After packaging, the project is manager.war, that is, after deployment, the front-end access path should be/manager, but all AXIos requests are relative to the root path, for example, this login request:As a result, a bunch of 404’s popped out at the front end, which was discovered by comparing network requests for the backup project with those for the current project.

Hide so deep, I wrote half a year ago the end of the people, how may know!

The revelation of

I thought it was just a matter of putting several WAR packages. Based on my understanding of Tomcat, there was no exception in logs, so I judged that the deployment process was ok, but the front page was always blank. After mustering up the courage to be hated and asking a dozen questions of former colleagues, I finally figured out the problems to be paid attention to behind this simple deployment.

The upshot is that packing is an extremely patient task, and it takes a long time, so you have to start all over again if you have any problems:

  1. MVN -x clean install once, when smooth, 40 minutes, forget to close the FTP directory, resulting in clean half failed, but also need to restart;
  2. Then upload six or seven 150MB files with the speed of 90Kb/s directly through the 50M network. The upload will be completed in half an hour to 40 minutes, depending on luck.
  3. Restart Tomcat for 5 minutes.
  4. I was interrogated by the leader on QQ for 3 times and pressed by phone for 2 times, totaling 20 minutes;
  5. It took an hour to compare the problem package with the normal package, and to find the problem by comparing it.

Yesterday packaging this matter, also let me deeply understand the IT industry personnel change time cost is how big ah! These problems are deeply experienced by the original person responsible for the pit, not handed over to the later person, the latter again through an investigation, although the cost is the enterprise, but the party may be their own.

Therefore, documentation is very important. Today, there is a packing note in the DOC directory of the company’s products. Let me end this problem on my hands. That’s what records are for!