使用maven的自动部署功能可以很方便的将maven工程自动部署到远程tomcat服务器,节省了大量时间。
本文章适用于tomcat的7.x ,8.x, 9.x版本。
下面是自动部的步骤
1,首先,配置tomcat的manager
编辑远程tomcat服务器下的conf/tomcat-users.xml,在末尾增加(其实只要拉到文件末尾,去掉注释改一下就可以了)
1
2
3
4
|
< role rolename = "manager-gui" /> < role rolename = "manager-script" /> < user username = "admin" password = "password" roles = "manager-script" /> < user username = "root" password = "password" roles = "manager-gui" /> |
将上面的password改为自己的密码,注意对于tomcat9来说,不能同时赋予用户manager-script和manager-gui角色。
保存tomcat-users.xml。
在tomcat服务器的conf/catalina/localhost/目录下创建一个manager.xml文件,写入如下值:
1
2
3
4
5
|
<? 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 > |
保存退出。
然后在浏览器中输入http://serverip:port/manager/html,此时会弹出要求输入用户名和密码对话框,输入manager-gui对应的用户和密码登录管理控制台(其中serverip为服务器ip,如果服务器在本地就是localhost或者127.0.0.1,端口为tomcat端口,默认8080)。以此确认manager是否配置正确。正确结果示例如下:
2,在maven项目中添加配置
在pom.xml文件中,在plugins节点下添加如下plugin节点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
< 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 > |
将上面的serverip和port换成自己tomcat服务器的ip和端口。密码换成上面配置的manager-script角色的密码。path改为项目在tomcat服务器中的部署路径。
然后进行部署,如果是第一次部署,运行mvn tomcat7:deploy进行自动部署(对于tomcat8,9,也是使用tomcat7命令),如果是更新了代码后重新部署更新,运行mvn tomcat7:redeploy,如果第一次部署使用mvn tomcat7:redeploy,则只会执行上传war文件,服务器不会自动解压部署。如果路径在tomcat服务器中已存在并且使用mvn tomcat7:deploy命令的话,上面的配置中一定要配置<update>true</update>,不然会报错。
如果ide是eclipse,就在runas->run configurations中配置一个maven build,intellij类似。
3. 内存泄漏
使用上面的方法进行部署后会出现严重的内存泄漏现象。tomcat的manager提供了诊断在部署时是否产生内存泄漏的功能,在上面提到的http://serverip:port/manager/html这个页面底部有一个“find leaks”的按钮,如下:
点击按钮,网页头部出现如下信息说明在部署的时候有内存泄漏:
上面的消息显示部署的test项目存在内存泄漏,如果同一项目多次重新部署,则一个项目名可能会出现多次。
部署时产生内存泄漏的原因是每次(重新)部署时,tomcat会为项目新建一个类加载器,而旧的类加载器没有被gc回收。maven的库classloader-leak-prevention-servlet可以用来解决这个问题。具体方案为:
(1)添加maven依赖:
1
2
3
4
5
|
< dependency > < groupid >se.jiderhamn.classloader-leak-prevention</ groupid > < artifactid >classloader-leak-prevention-servlet</ artifactid > < version >2.1.0</ version > </ dependency > |
(2)在项目的web.xml中添加一个listener(必须让此listener成为web.xml中的第一个listener,否则不起作用)
1
2
3
|
< listener > < listener-class >se.jiderhamn.classloader.leak.prevention.classloaderleakpreventorlistener</ listener-class > </ listener > |
这样部署时的内存泄漏就解决了。
注意:
1) 添加这个listener后,默认在tomcat关闭5s后jvm会进行内存回收的操作,具体时间设置可在下面的第三个参考链接中找到,所以,在关闭后的5s内,再次启动tomcat,可能会存在问题,导致启动无效(如果出现tomcat重启后日志显示正常但是服务器不工作的话考虑一下是不是这个问题)。
2)这个listener只解决部署的内存泄漏,其他问题(如jdbc等)产生的内存泄漏还需要自己解决。
参考:
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,错误排除。
(1) 执行tomcat7:deploy显示build success成功但是没有效果,也没有在本地生成war包,检查一下maven配置文件中packaging标签是否设置为war。即:
<packaging>war</packaging>
如果不是(比如说是pom),那么改成war应该就可以了。
(2) 如果出现在本地tomcat服务器自动部署没有任何问题,部署到远程服务器出现下面的cannot invoke tomcat manager: connection reset by peer: socket write error 错误:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
[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 |
使用mvn tomcat7:redeploy时出现如下情况
经过查询tomcat文档后发现,这是由于tomcat的远程地址拦截器造成的结果,默认情况下,tomcat的manager和host-manager只接受本机的请求,而要让它接受远程的请求,需要添加上面提到的manager.xml的配置(第一步配置过了就不要加了),也就是:
1
2
3
4
5
|
<? 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 > |
由于tomcat的manager可以执行项目的部署、卸载等敏感操作,如果你只想允许特定的ip地址访问manager,可在上面的allow属性中设置规则。具体规则设置见下面的链接:
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#remote_address_filter
问题说明:http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#configuring_manager_application_access
(3)自动部署显示成功,war包也上传成功,但是war不自动解压自动部署。
如果你在tomcat的server.xml中通过设置<context>标签来部署相同名称的项目的话,maven发布到该服务器的war不会被自动解压,部署,更新,需要去掉server.xml中该项目的<context>标签。
5. 其他
如果想要实现对部署路径加版本,可将上面tomcat7-maven-pluginconfiguration的path设置为
<path>/webapp#version</path>
的形式,部署后,当前项目在服务器端的路径就是/webapp/version。举个例子,如果path设置为 test#1.0,那么服务端项目实际的路径就是/test/1.0。如下:
如果名字和版本号之间是两个#,效果就是制定当前项目在manager网页中显示的版本,路径不变,举个例子,path设置为test##1.0,实际部署路径为/test,但是在manager网页中,显示如下,注意version一栏的值:
参考:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#naming
原文链接:http://www.cnblogs.com/xyb930826/p/5725340.html