An error is reported when tomcat is started. The error contents are as follows

serious: A child container failed during start
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost]]
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.startup.Tomcat.start(Tomcat.java:341)
	at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.startContainer(AbstractRunMojo.java:1238)
	at org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo.execute(AbstractRunMojo.java:592)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:972)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:47)

The following servlet dependencies are added to the code changes. After removal, the system can be started successfully. However, if the project reference is removed, an error will be reported,
It is inferred that adding servlet dependencies causes conflicts with other dependencies when packaging.

Solutions

You only need to add the scope tag in the dependency to exclude the servlet API we introduced when packaging the project, as shown below.

Digression, classification of scope

In Maven's default dependency configuration item, the default value of scope is compile. Projects are often confused and default. Today, let's sort out Maven's scope.

• Compile: the default is compile. Nothing is configured, which means compile. Compile means that the dependent project needs to participate in the compilation of the current project. Of course, subsequent tests and running cycles are also involved. It is a strong dependency. It usually needs to be included when packaging.
• Test:scope is test, which means that the dependent project only participates in test related work, including the compilation and execution of test code. Typical examples are junit.
• Runntime: it means that the dependent project does not need to participate in the compilation of the project, but it needs to participate in the later test and run cycle. Compared with compile, it only skips compilation. To be honest, in terminal projects (non open source, enterprise internal systems), it is not very different from compile. Common ones such as JSR ××× The corresponding API jar is compiled, and the specific implementation is runtime. It is sufficient for compile to only know the interface. The oracle jdbc driver rack package is A good example. Generally, the scope is runntime. In addition, the runntime dependency is usually used with optional, which is true. I can use either A or B.
• Provided:provided means that you don't need to package it when packaging. Other facilities (Web Container) will provide it. In fact, the dependency can theoretically participate in compilation, testing, and running cycles. It is equivalent to compile, but the exclude action is performed in the packaging phase.
• System: in terms of participation, it is also the same as provided. However, the dependent items are not captured from the maven warehouse, but from the local file system. They must be used in conjunction with the systemPath attribute.