Maven automatically deploys to remote tomcat tutorial

Using maven's automatic deployment function can easily automatically deploy maven projects to remote tomcat servers, saving a lot of time.

This article applies to the 7.x, 8.x, 9.x versions of tomcat.

The following are the steps of the automatic part

1. First, configure the manager of tomcat

Edit conf/tomcat-users.xml under the remote tomcat server and add it at the end (in fact, just pull to the end of the file, remove the comment and change it)

<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="admin" password="password" roles="manager-script"/>
<user username="root" password="password" roles="manager-gui"/>

Change the above password to your own password. Note that for tomcat9, the user manager-script and manager-gui roles cannot be assigned at the same time.

Save tomcat-users.xml.

Create a manager.xml file in the conf/Catalina/localhost/ directory of the tomcat server and write the following values:

<?xml version="1.0" encoding="UTF-8"?>
<Context privileged="true" antiResourceLocking="false"
         docBase="${catalina.home}/webapps/manager">
             <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="^.*$" />
</Context>

Save and exit.

Then enter http://serverip:port/manager/html in the browser, a dialog box will pop up asking for the user name and password, enter the user and password corresponding to manager-gui to log in to the management console (where serverip is the server ip, If the server is localhost or 127.0.0.1 locally, the port is the tomcat port, the default is 8080). This confirms that the manager is configured correctly. An example of the correct result is as follows:

2. Add configuration to maven project

In the pom.xml file, add the following plugin node under the plugins node

<plugin>

    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.2</version>

    <configuration>
        <url>http://serverip:port/manager/text</url>
        <username>admin</username>
        <password>password</password>
        <update>true</update>
        <path>/webapp</path>
    </configuration>

</plugin>

Replace the above serverip and port with the ip and port of your own tomcat server. Change the password to the password of the manager-script role configured above. path is changed to the deployment path of the project in the tomcat server.

Then deploy, if it is the first deployment, run mvn tomcat7:deploy for automatic deployment (for tomcat8,9, also use the tomcat7 command), if it is to redeploy the update after updating the code, run mvn tomcat7:redeploy, if the first If the second deployment uses mvn tomcat7:redeploy, only the war file will be uploaded, and the server will not automatically decompress the deployment. If the path already exists in the tomcat server and the mvn tomcat7:deploy command is used, <update>true</update> must be configured in the above configuration, otherwise an error will be reported.

If the IDE is eclipse, configure a maven build in runas->run configurations, similar to intellij.

3. Memory leak

There will be serious memory leaks after deployment using the above method. The manager of tomcat provides the function of diagnosing whether memory leaks occur during deployment. There is a "Find leaks" button at the bottom of the above-mentioned http://serverip:port/manager/html page, as follows:

Click the button, and the following information appears in the header of the web page, indicating that there is a memory leak during deployment:

The above message shows that the deployed test project has a memory leak. If the same project is redeployed multiple times, a project name may appear multiple times.

The reason for the memory leak when deploying is that every time you (re)deploy, Tomcat will create a new class loader for the project, and the old class loader is not reclaimed by the GC. The maven library classloader-leak-prevention-servlet can be used to solve this problem. The specific plans are:

(1) Add maven dependencies:

<dependency>
    <groupId>se.jiderhamn.classloader-leak-prevention</groupId>
    <artifactId>classloader-leak-prevention-servlet</artifactId>
    <version>2.1.0</version>
</dependency>

(2) Add a Listener to the web.xml of the project ( this Listener must be the first Listener in web.xml, otherwise it will not work )

<listener>
    <listener-class>se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventorListener</listener-class>
</listener>

In this way, the memory leak when deploying is solved.

Notice:

1) After adding this Listener, the jvm will perform the memory recovery operation by default after tomcat is closed for 5s. The specific time setting can be found in the third reference link below. Therefore, within 5s after closing, start tomcat again, maybe There will be problems, resulting in invalid startup (if the log shows normal after tomcat restarts but the server does not work, consider whether this is the problem).

2) This Listener only solves the memory leak of deployment, and the memory leak caused by other problems (such as jdbc, etc.) needs to be solved by itself.

refer to:

http://stackoverflow.com/questions/7788280/memory-leak-when-redeploying-application-in-tomcat#answer-36295683

http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/

https://github.com/mjiderhamn/classloader-leak-prevention

4. Error elimination.

(1) Executing tomcat7:deploy shows that the Build Success is successful but has no effect, and the war package is not generated locally. Check whether the packaging tag in the maven configuration file is set to war. which is:

<packaging>war</packaging>

If not (for example, pom), then changing to war should be fine.

(2) If there is no problem with automatic deployment on the local tomcat server, the following Cannot invoke Tomcat manager: Connection reset by peer: socket write error error appears when deployed to the remote server:

[ERROR] Failed to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.2:deploy (default-cli) on project webapp: Cannot invoke Tomcat manager: Connection reset by peer: socket write error -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.tomcat.maven:tomcat7-maven-plugin:2.2:deploy (default-cli) on project clyf_wechat: Cannot invoke Tomcat manager
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke Tomcat manager
    at org.apache.tomcat.maven.plugin.tomcat7.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:141)
    at org.apache.tomcat.maven.plugin.tomcat7.AbstractWarCatalinaMojo.execute(AbstractWarCatalinaMojo.java:68)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
    ... 20 more
Caused by: java.net.SocketException: Connection reset by peer: socket write error
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
    at org.apache.http.impl.io.AbstractSessionOutputBuffer.write(AbstractSessionOutputBuffer.java:181)
    at org.apache.http.impl.io.ContentLengthOutputStream.write(ContentLengthOutputStream.java:115)
    at org.apache.tomcat.maven.common.deployer.TomcatManager$RequestEntityImplementation.writeTo(TomcatManager.java:880)
    at org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:89)
    at org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
    at org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:117)
    at org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:265)
    at org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:203)
    at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:236)
    at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:121)
    at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682)
    at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
    at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.tomcat.maven.common.deployer.TomcatManager.invoke(TomcatManager.java:742)
    at org.apache.tomcat.maven.common.deployer.TomcatManager.deployImpl(TomcatManager.java:705)
    at org.apache.tomcat.maven.common.deployer.TomcatManager.deploy(TomcatManager.java:388)
    at org.apache.tomcat.maven.plugin.tomcat7.deploy.AbstractDeployWarMojo.deployWar(AbstractDeployWarMojo.java:85)
    at org.apache.tomcat.maven.plugin.tomcat7.deploy.AbstractDeployMojo.invokeManager(AbstractDeployMojo.java:82)
    at org.apache.tomcat.maven.plugin.tomcat7.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:132)
    ... 23 more

The following occurs when using mvn tomcat7:redeploy

After querying the Tomcat documentation, I found that this is the result of Tomcat's remote address interceptor. By default, Tomcat's Manager and Host-Manager only accept local requests, but to make it accept remote requests, you need to add the above The configuration of the mentioned manager.xml (do not add it after the first step is configured), that is:

<?xml version="1.0" encoding="UTF-8"?>
<Context privileged="true" antiResourceLocking="false"
         docBase="${catalina.home}/webapps/manager">
             <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="^.*$" />
</Context>

Since Tomcat's Manager can perform sensitive operations such as project deployment and uninstallation, if you only want to allow specific IP addresses to access the Manager, you can set the rules in the allow attribute above. For specific rule settings, see the link below:

http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Address_Filter

Problem description: http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access

(3) The automatic deployment is displayed successfully, and the war package is also uploaded successfully, but the war is not automatically decompressed and automatically deployed.

If you deploy a project with the same name by setting the <Context> tag in tomcat's server.xml, the war published by maven to the server will not be automatically decompressed, deployed, and updated. You need to remove the <Context> tag of the project in server.xml. Context > tab.

5. Others

If you want to add the version to the deployment path, you can set the path of the above tomcat7-maven-plugin configuration to

<path>/webapp#version</path>

After deployment, the path of the current project on the server side is /webapp/version. For example, if the path is set to test#1.0, then the actual path of the server project is /test/1.0. as follows:

If there are two #s between the name and the version number, the effect is to formulate the version of the current project displayed in the manager webpage, and the path remains unchanged. For example, the path is set to test##1.0, and the actual deployment path is /test, but in On the manager web page, the display is as follows, pay attention to the value of the Version column:

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　-- over --