maven自动部署到远程tomcat教程

使用maven的自动部署功能可以很方便的将maven工程自动部署到远程tomcat服务器,节省了大量时间。

本文章适用于tomcat的7.x ,8.x, 9.x版本。

下面是自动部的步骤

1,首先,配置tomcat的manager
编辑远程tomcat服务器下的conf/tomcat-users.xml,在末尾增加(其实只要拉到文件末尾,去掉注释改一下就可以了)

<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文件,写入如下值:

<?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节点

复制代码

<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命令的话,上面的配置中一定要配置true,不然会报错。

如果IDE是eclipse,就在runas->run configurations中配置一个maven build,intellij类似。

  1. 内存泄漏
    使用上面的方法进行部署后会出现严重的内存泄漏现象。tomcat的manager提供了诊断在部署时是否产生内存泄漏的功能,在上面提到的http://serverip:port/manager/html这个页面底部有一个“Find leaks”的按钮,如下:

点击按钮,网页头部出现如下信息说明在部署的时候有内存泄漏:

上面的消息显示部署的test项目存在内存泄漏,如果同一项目多次重新部署,则一个项目名可能会出现多次。

部署时产生内存泄漏的原因是每次(重新)部署时,Tomcat会为项目新建一个类加载器,而旧的类加载器没有被GC回收。maven的库classloader-leak-prevention-servlet可以用来解决这个问题。具体方案为:

(1)添加maven依赖:

<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,否则不起作用)

<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。即:

war
如果不是(比如说是pom),那么改成war应该就可以了。

(2) 如果出现在本地tomcat服务器自动部署没有任何问题,部署到远程服务器出现下面的Cannot invoke Tomcat manager: Connection reset by peer: socket write error 错误:

[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的配置(第一步配置过了就不要加了),也就是:

Cannot invoke Tomcat manager: sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed:
NotAfter: Thu Aug 16 07:59:59 CST 2018
  1. 其他
    如果想要实现对部署路径加版本,可将上面tomcat7-maven-pluginconfiguration的path设置为

/webapp#version
的形式,部署后,当前项目在服务器端的路径就是/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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Alpha / Beta /Stable 当为发布投票时,审阅者指定他们认为发布已达到的稳定性级别。一个新的主要版本的初始版本通常在几个月的时间内从Alpha过渡到Beta到Stable。但是,稳定级别仅在Java规范发布实现已完成时可用。这意味着在所有其他方面被认为稳定的版本,如果规格不是最终的,仍然可以标记为Beta。 下载页面将始终显示最新的稳定版本和任何新的Alpha或Beta版本(如果存在)。Alpha和Beta版本始终在下载页面上清楚地标记。 稳定性是一个主观判断,你应该总是仔细阅读版本注释任何版本,你打算使用。如果你是一个释放的早期采用者,我们很乐意听到你关于它的稳定性意见,表决部分:它发生在上开发邮件列表。 Alpha版本可能含有大量的规范和/或显著的bug需要未经测试/缺少的功能,并且预计不会稳定地任何时间运行。 Beta版本中可能含有一些未经测试的功能和/或一些相对较小的错误。Beta版本预计不会稳定运行。 Stable的版本可能包含少量相对较小的错误。稳定的释放用于生产使用,预计可以稳定运行长时间。 Apache Tomcat 9.x Apache Tomcat上9.x的是发展的当前焦点,它建立在Tomcat 8.0.x和实现了目前草案的Servlet 4.0规范,也将执行 JSP 2.4?,EL 3.1?,目前对WebSocket的1.2? 和JASPIC 1.1 规范工作的一次更新上这些规范为Java EE 8除此之外启动时,它包括以下显著改进: 添加对HTTP / 2的支持(需要APR /本地库) 添加对TLS虚拟主机的支持 添加了对使用JSSE连接器(NIO和NIO2)使用OpenSSL for TLS支持的支持。 Apache Tomcat 8.x 的Apache Tomcat 8.x的建立在Tomcat的7.0.x并实施 的Servlet 3.1,JSP 2.3,EL 3.0 和WebSocket的1.1规格。除此之外,还包括以下重大改进: 单个公共资源实现来替换早期版本中提供的多个资源扩展特性。 的Apache Tomcat 8.5.x的支持相同的Servlet,JSP,EL和WebSocket规范的版本的Apache Tomcat 8.0.x. 除此之外,它也实现了JASPIC 1.1规范。还有在许多领域显著变化引擎盖下,从而提高了性能,稳定性和总拥有成本。有关详细信息,请参阅Apache Tomcat 8.5更改日志。 Apache Tomcat 7.x 的Apache Tomcat 7.x的建立在Tomcat中6.0.x的改进和实现的Servlet 3.0, JSP 2.2,EL 2.2和 WebSocket的1.1规格。除此之外,它还包括以下改进: Web应用程序内存泄漏检测和预防 提高了Manager和Host Manager应用程序的安全性 通用CSRF保护 支持直接在Web应用程序中包含外部内容 重构(连接器,生命周期)和大量的内部代码清理 Apache Tomcat 6.x 的Apache Tomcat 6.x的建立在Tomcat中的5.5.x的改进和实现的Servlet 2.5和 JSP 2.1规范。除此之外,它还包括以下改进: 内存使用优化 高级IO功能 重构聚类 Tomcat的6的用户应该知道,Tomcat的团队已经公布了 的生命日期为Tomcat 6.x的结束。Tomcat 6.x的用户应该计划在Tomcat 6.x到达生命周期之前进行升级。 Apache Tomcat 5.x 的Apache Tomcat 5.x的是可以从档案下载。 的Apache Tomcat 5.5.X支持相同的Servlet和JSP规范版本的的Apache Tomcat 5.0.x中 还有在许多领域显著变化引擎盖下,从而提高了性能,稳定性和总拥有成本。有关详细信息,请参阅Apache Tomcat 5.5 Changelog。 的Apache Tomcat 5.0.x版在很多方面在Apache Tomcat 4.1的改进,其中包括: 性能优化和减少的垃圾收集 重构的应用程序部署器,具有可选的独立部署器,允许在Web应用程序投入生产之前进行验证和编译 使用JMX和管理器Web应用程序完成服务器监视 可扩展性和可靠性增强 改进了Taglibs的处理,包括高级池和标签插件 改进的平台集成,与本机Windows和Unix包装器 使用JMX嵌入 增强的安全管理器支持 集成会话聚类 扩展文档 Apache Tomcat 4.x 的Apache Tomcat 4.x版可以从档案下载。 的Apache Tomcat 4.x的实现了基于全新架构的新的servlet容器(称为卡特琳娜)。4.x的版本中实现的Servlet 2.3和JSP 1.2 规范。 的Apache Tomcat 4.1.x的是的Apache Tomcat 4.0.x的的重构,并含有显著增强功能,包括: 基于JMX的管理功能 JSP和Struts的管理Web应用程序 新的Coyote连接器(HTTP / 1.1,AJP 1.3和JNI支持) 重写Jasper JSP页面编译器 性能和内存效率提高 增强了与开发工具集成的管理应用程序支持 自定义Ant任务可以直接从build.xml脚本与管理器应用程序交互 的Apache Tomcat 4.0.x的。Apache Tomcat 4.0.6是旧的生产质量版本。4.0 servlet容器(卡塔利娜)已经从地上爬起来的灵活性和性能开发。4.0版实现了Servlet 2.3和JSP 1.2规范的最终发布版本。根据规范的要求,Apache Tomcat 4.0还支持为Servlet 2.2和JSP 1.1规范构建的Web应用程序,无需更改。 Apache Tomcat 3.x Apache Tomcat上3.X可以从档案下载。 版本3.3是当前生产质量放行了Servlet 2.2和JSP 1.1规范。Apache Tomcat 3.3是Apache Tomcat 3.x体系结构的最新延续; 它比3.2.4更先进,这是“老”的生产质量释放。 版本3.2.4是“旧的”生产质量版本,现在仅在维护模式。 版本3.1.1是旧版本。 所有的Apache Tomcat 3.X版本跟踪其遗产回到原来的Servlet和JSP实现,Sun公司捐赠给Apache软件基金会。该3.X版本都实现了支持Servlet 2.2和JSP 1.1规范。 的Apache Tomcat 3.3.X。版本3.3.2是当前的生产质量版本。它继续在3.2版本中开始的重构,并将其转化为其逻辑结论。3.3版本提供了更多的模块化设计,允许通过添加和删除控制servlet请求处理的模块来定制servlet容器。此版本还包含许多性能改进。 的Apache Tomcat 3.2.X。版本3.2自3.1以来增加了几个新功能; 主要的努力是重构内部以提高性能和稳定性。3.2.1版本,如3.1.1,是一个安全补丁。版本3.2.2修复了大量的错误和所有已知的规范合规性问题。版本3.2.3是一个安全更新,关闭一个严重的安全漏洞。版本3.2.4是一个小错误修复版本。所有Apache Tomcat 3.2.3之前版本的用户都应该尽快升级。除了修复关键安全相关的错误,Apache Tomcat 3.2.x分支上的开发已停止。 的Apache Tomcat 3.1.X。3.1版本包含对Apache Tomcat 3.0的几个改进,包括servlet重新加载,WAR文件支持和为IIS和Netscape Web服务器添加的连接器。最新的维护版本3.1.1包含了对安全问题的修复。Apache Tomcat 3.1.x没有进行积极的开发。Apache Tomcat 3.1的用户应该更新到3.1.1以关闭安全漏洞,强烈建议他们迁移到当前的生产版本Apache Tomcat 3.3。 的Apache Tomcat 3.0.x的。初始Apache Tomcat版本。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值